Federation TODO list

be warned, this issue is more stream of consciousness

Meta

• write docs about how shoot federation works and why
• write some feps asking for feedback from community about Roles, Guilds (Organisations containing Groups/fep1b12), voice chats
• write more federation tests
• • how do I test interop with Mastodon and other projects? maintaining a Mastodon test interface would suck. do other projects not do automated interop testing?

---

AP type vocab	Shoot concept
Person	User
Group	GuildTextChannel
Organisation	Guild
Role	Role

activity -> destination

Relationships

• Follow<Person> -> Person send a friend request
• Accept<Follow<Person>> -> Person accept a friend request
• Undo<Follow<Person>> -> Person undo a friend request
• To block a user, undo any follows then prevent future follows and ignore any activities from them
• ... other state changes

Guilds

• Follow<Organisation> -> Organisation use an invite code to join a guild.
• Accept<Follow<Organisation>> -> Person accept the join request.
• Undo<Follow<Organisation>> -> Person kick a user from a guild or remove yourself from it
• To ban a user, kick them then disallow future join requests
• Update<Guild> -> Person broadcast updates about a guild
• ... other state changes
• Fix federation of offline guilds (display them as unavailable in the client??)
• Don't allow fetching guild members, roles, etc when you aren't in the guild
• Don't block when fetching remote guilds

Roles

the Role type is a custom object type for Shoot. more thought is required on whether this is necessary
might be useful to write a FEP or something

• Create<Role> -> Person broadcast creation of new roles in guilds
• Update<Role> -> Person update the role
• Delete<Role> -> Person delete the role
• Join<Role> -> Person indicate someone has joined the role
• Leave<Role> -> Person indicate someone has left the role
• ...other activities for state changes for roles and their members

Messaging

• Implement fep-1b12. This could already be done, but I haven't double checked
• Create<Note> -> Person send a DM
• Create<Note> -> Group send a message to a channel (group) in a guild
• Like<Note> -> Group|Person react to a message
• Undo<Create<Note>> -> Group|Person delete a message
• Announce<Create<Note>> -> Person the current behaviour of this might conflict with fep-1b12
• ... other state changes
• convert incoming HTML to markdown and convert markdown to HTML for federation

Greater-Activitypub object viewing

Shoot is primarily a messaging platform, not a microblogging service or anything like that.
I don't think I want to include features related to posting to your account? However having this ability would be good publicity probably, since then I can make some announcement post from my maddy@understars.dev shoot outbox that shows up in mastodon/etc. At the moment, basically everything is private and requires an authorised user (via http signatures) to access

I guess embeds solve the problem of viewing remote objects? send a link to whatever federated object and show a great embed of it or something.

might be good to allow interactions of remote objects e.g. voting in polls, liking messages, etc
but if I'm allowing that, then usability dictates I have to also include some way to view a post without sending a message to generate an embed first.
and if I allow interacting with remote objects, I have to store them, and then it's basically trivial to just show an entire outbox anyway... blehhhh

Voice chats

Federated voice chats need more thought. Currently, users send Join<Group> to send a vc join request to the server that owns the channel/group, which responds with a Accept<Join<Group>> containing a voice token and the webrtc signaling address to use to join the corresponding voice chat.

This is not my ideal... Obviously this exposes users to unknown webrtc signaling servers, and Shoot currently only supports non-e2ee SFU architecture therefore the remote server has all the call data.

I had previously considered a setup where everyone joins their own homeservers SFU, and then there are bridging connections between all the servers that forwards . But this isn't great either because then you have to maintain N=number of home user streams * M=number of foriegn servers so that each server can control each foreign user's stream individually (for things like mute/block/vol control) OR you have one stream per foreign server and lose all of that control

so... peer to peer federated voice chats? how does matrix do it?
p2p will kind of suck for many participants but I guess shoot is probably not reaching a scale where that matters lol

No file, test, or entry point is named; start by narrowing the checklist to one item and, for the messaging item, read the linked FEP-1b12. Define the chosen behavior and its completion criteria before investigating the existing federation implementation and relevant interoperability or state-change tests.