Support multiple Mastodon instances #22

New Issue

2021-08-31T16:56:21Z

danieljsummers commented

2021-08-31 16:56:21 +00:00

(Migrated from github.com)

EDIT: See this comment for the actual required changes. The remainder of this text is obsolete

This was originally limited to No Agenda Social users; however, since its inception, NAS has closed membership a few times, and other No Agenda instances have been stood up. These users should be allowed to sign in as well.

Implement this in configuration, as it is likely to be a non-static list of affiliated instances.

EDIT: See [this comment](#issuecomment-909544203) for the actual required changes. The remainder of this text is obsolete This was originally limited to No Agenda Social users; however, since its inception, NAS has closed membership a few times, and other No Agenda instances have been stood up. These users should be allowed to sign in as well. Implement this in configuration, as it is likely to be a non-static list of affiliated instances.

danieljsummers commented

2021-08-31 16:57:38 +00:00

(Migrated from github.com)

Initial instances - itmslaves.com and libertywoof.com

Initial instances - `itmslaves.com` and `libertywoof.com`

danieljsummers commented

2021-08-31 19:17:13 +00:00

(Migrated from github.com)

This is more involved than I originally thought; it will be v2.1. More details to follow.

danieljsummers commented

2021-08-31 19:31:36 +00:00

(Migrated from github.com)

This will require the following changes:

Jobs, Jobs, Jobs will need to be registered for API access with each Mastodon instance supported
The Log On page will need to display a link/button for each supported instance, so requests can be routed to the appropriate one
Each return URL will need to be unique, so that we can verify the account and update information from the appropriate instance.
The instance will need to be stored with the Citizen record, as neither the username or account name fields will have that if we get the info from the "home" instance.
All links to user profiles should direct users to the appropriate instance. Additionally, create a "copy to clipboard" button where each citizen's full Mastodon handle [name]@[instance] is placed in the user's clipboard; this will facilitate a flow like "click -> go to Mastodon tab -> paste into new message box" for DMs concerning listings and profiles.
Throughout the application and help, references to "No Agenda Social" will need to be changed to the user's actual instance (if they are logged on), or a generic "your Mastodon instance" for pages displayed to non-logged-on users.
This still should be configuration-driven; create a section for each supported instance. Create API endpoints to retrieve the available instances and generate the links/buttons accordingly. This will allow new instances to be added "live", without requiring an additional release of the application.

This will require the following changes: * Jobs, Jobs, Jobs will need to be registered for API access with each Mastodon instance supported * The Log On page will need to display a link/button for each supported instance, so requests can be routed to the appropriate one * Each return URL will need to be unique, so that we can verify the account and update information from the appropriate instance. * The instance will need to be stored with the Citizen record, as neither the username or account name fields will have that if we get the info from the "home" instance. * All links to user profiles should direct users to the appropriate instance. Additionally, create a "copy to clipboard" button where each citizen's full Mastodon handle `[name]@[instance]` is placed in the user's clipboard; this will facilitate a flow like "click -> go to Mastodon tab -> paste into new message box" for DMs concerning listings and profiles. * Throughout the application and help, references to "No Agenda Social" will need to be changed to the user's actual instance (if they are logged on), or a generic "your Mastodon instance" for pages displayed to non-logged-on users. * This still should be configuration-driven; create a section for each supported instance. Create API endpoints to retrieve the available instances and generate the links/buttons accordingly. This will allow new instances to be added "live", without requiring an additional release of the application.

Sign in to join this conversation.