Seems like GNU Social doesn't always load or update avatars of Mastodon users. Not clear if it's their bug or ours.

There should be a way to edit your e-mail address, change password, and manage e-mail notifications from the UI.

When a status is removed in the back-end, the front-end must remove it as well.

Assuming a local representation of a remote account is created from an incoming Salmon or reblog, in which case no PuSH subscription is established (i.e. the Mastodon server does not want to receive the user's feed updates).

It becomes possible to follow that user using the /api/accounts/:id/follow end-point.

Expected behaviour: A PuSH subscription is then established. A Salmon slap is sent to the remote user.

Current behaviour: No PuSH subscription is established. No Salmon slap is sent.

Not every "error" has a response property

Mastodon already uses Redis for timelines. The fan-out-on-write system merely needs to make a publish call to an appropriate Redis channel. ActionController::Live can be used to create the API end-point.

Current behaviour: A single public status page displays the status it is an immediate response to, and all statuses that are immediate replies to it.

Expected behaviour: Display as much context as possible, by resolving all connected statuses, not just immediate replies.

Potential problems:

1. Given local status A, and remote reply B. If somebody replies to B, the instance A is on does not get notified.
2. Given remote status A, and local reply B, it is impossible to fetch A's other responses (B's remote siblings)

Problem 1. shouldn't be a problem if the replies still mention A's user, in which case A's instance gets a Salmon slap. However, technically, in-text mentions are not neccessary for threads in OStatus.

They are ordered by ID rather than by tree path because of how order of WHERE IN queries is not preserved.

To help the 3rd party app ecosystem, add "posted from [Application Name]" type information to statuses.

"GNU social", not "GNU Social" :)

Currently only home timeline and mention timeline updates are streamed to the user via ActionCable. But it doesn't have to be this way! Literally anything could be streamed:

• User's status has been favourited/reblogged
• User got a new follower
• User unfollowed someone (can be used to quickly clean up UI)

When unfollowing a user, the home feed should be purged of the unfollowed user's posts.

This could be done by simply removing the whole feed, forcing a PrecomputeFeedService on next access.

When following an account, that account's statuses need to be merged into the user's home timeline.

OAuth is great for allowing all sorts of 3rd party apps to flourish around the API, but thinking it through, I am encountering a small obstacle. Each app requires a client ID and secret on the instance it wants to work with (so it needs to be pre-registered). This means that each app needs to be tailored for a specific instance of Mastodon, but it's not like each app could connect to whatever instance the user wanted it to.

How could this be solved?

Alphanumeric only.

It should be possible to blacklist users or domains from appearing in your mentions/notifications.

Multiple reblogs of the same status do not need to be shown, only the latest one.

Mastodon should provide an Admin dashboard with an overview of what is happening behind the scenes:

• How many local users do we have?
• How many remote users are we subscribed to?
• What other instances are we aware of?
• How many local statuses are we hosting?

Furthermore, the admin dashboard should be the place where account or status suspensions from #9 should be managed.

So that 3rd party apps can get their client key/secret and use OAuth2.

Big networks like Twitter and Facebook have a complicated, user-bound app registration process to have better control and credibility, so one app has one entry in their database or whatever. But in a decentralized network, that's not really possible. Just let apps register themselves, and if one app has multiple database entries/tokens, whatever, so be it. The real point is to have a secure user authorization process that doesn't involve revealing the user's password to 3rd parties.

Happened for one remote account, /follows endpoint gave 500 and /accounts/:id/follow was a no-op

All APIs need to be rate-limited to prevent abuse.

If a status from a user who is not followed by anyone on the instance gets delivered via Salmon, and is then consequently deleted on the remote source (because of a typo or other mistake), the instance does not get notified of this.

As a consequence the mentions timeline can be spammed with minor corrections, which is annoying.

This could be fixed if GNU Social and Mastodon made sure to send a follow-up Salmon with a deletion request when such a status is deleted on their end. But handling of deletion requests needs to be implemented in Mastodon, as well.

Since no client UI is provided, until the user setups a 3rd party app to interact with Mastodon, there is no way to know when you've been followed or mentioned, reblogged or favourited.

E-mail notifications are needed. They should be opt-out. User settings are required for this.

A big % of the response time in the app is rendering partials (not even SQL queries). So the response time could be improved significantly by caching fragments.

This isn't pressing since we're talking 500ms vs maybe 200ms here.

Add pagination to public account pages and add Atom feed pagination as well.

Currently the avatar of the remote user is re-downloaded every time we receive an update from them. It would be better to cache the remote URL and only re-download if the URL changed.

It should be possible, in case of abuse, for a Mastodon instance owner to suspend a user's account.

Suspension should hide the account and all statuses from public view. Suspension should be reversible.

It would be good to promote this on gnu.io, but with the current license it would be inappropriate. The GNU AGPL v3 or later versions would be a good license choice for this project.

For some reason when following people on GS, GS stopped showing the Mastodon account among followers. Not clear if it's their bug or ours.

In ProcessFeedService, if a remote status we want to save (A) is a response to another status (B), then we try to look up a local copy of B. If it fails, no reply-to information is saved.

It's up for debate if the method should then try to somehow fetch the B status. The potential problem with that approach would be that B is a reply to status C, etc etc indefinitely, which would force the Mastodon service to crawl the entire fediverse. That may not be wise.

Front-end should have a way of displaying statuses in conversation context, profiles (with the ability to follow/unfollow), also a form for updating own profile, and maybe a list of followees/followers.

Reblogs in Atom need a slightly different tag structure, and at the very least they need to include the <author /> of the <activity:object />. Current reblogs originating from Mastodon are malformed.

Statuses can have enclosures. It should be possible to upload pictures. Remote statuses should have their enclosures cached and displayed neatly.

Maybe I missed it, but I couldn't find any info on licensing for this project. It would be helpful if you added a LICENSE.md file to clear up any confusion.

I recommend "AGPLv3 or later", which is the same license used by GNU social itself. More info on it: https://en.wikipedia.org/wiki/Affero_General_Public_License

This is because a follow request dispatches a timeline refresh action, which is another request-success-fail cycle, however, the final action is not called TIMELINE_REFRESH_SUCCESS, instead it's the more legacy TIMELINE_SET which is not being picked up by the react-redux-loading-bar middleware. Solution is just to rename that.

FanOutOnWriteService needs to be improved: Currently it filters out statuses that are direct replies to people the home timeline owner does not follow himself (standard Twitter behaviour). However, most statuses are not direct replies, even if they're meant for somebody home owner does not follow. The status body actually needs to be check for if it begins with a mention.