use ActivityPub for server to server API

[maybeanerd]

I don't want to use a custom REST based event stream. I don't want to use graphQL here.

Let's use ActivityPub We can start easy A Server is a single actor Following is the "treaty" You can Post trades, and like to "confirm" them.

Let's make it actually be "compatible" with Mastodon. I't wont be any fun to follow a Game Server But it would be possible.

---

Might be nice to not embed game info in posts, but rather add AP extensions for the game. (Here's sime examples from mastodon: https://docs.joinmastodon.org/spec/activitypub/#toot)

This might allow for a post to describe the Action, e.g. "Basti wants to trade 5 wood for 5 steel in GameNameHere", and add the Game and Action meta to it in extensions. This would allow others to make sense of the posts, If they were to follow.

For Likes, one could probably add an extensions for the game as well, where it specifies the trade response and which player accepted, etc?

---

The single actor of the instance could be merchant@trading-game.yourDomain.com

---

An interesting thing to solve is: who to federate with Up until now I wanted a single server to only directly connect to a few others, and then allow trade proxied by them.

Maybe this is still possible by them creating Proxy-Posts? I also thought of discovering follower instances and directly following them, but w core Game mechanic will be travel duration or taxing for Proxy even, so I don't think that's a nice solution. Of course a game server can mark other instances they follow as "No direct Connection", but i Kind of Like the idea of there actually Not being a direct connection

---

To allow the wider integration into the fediverse, one could limit following only for Game instances, and allow any amount of other AP services to follow and interact without Limit. Internally the Game Server will ignore all of those actions in terms of gameplay, but will replicate and federate them like any other AP system would

---

next TODOs

• [x] Check all occurences of "id: randomUUID" to make sure we don't create AP Things with uuid ids (we definitely do right now). If e.g. activities are missing internalID, add that
• [x] treaty flow (unfollow)
• [x] rework internalID ( Use only for getters of activities and objects. Require them for self-created Things For mapping with game objects, remove on activities. Follow etc doesn't map to treaty, an actorID does. Remove from objects-> Store the APobjectId on the game objects (e.g. trade) instead)
• [x] trade flow (internal changes need to create activities and notes)
• [x] treaty flow <-> following in AP : maybe keep track of followers in addition to treaties: that way we know who to post things to, even if we dont follow them (e.g. a mastodon user following a gameserver)

inbox/outbox handlers

• [x] sending outbox stuff to all followers
• [x] delete outbox things after being sent
• [x] receiving follows
• [x] rework handler to map activities to more specific Things, e.g. undo to unfollow OR unLike. This should streamline downstream handlers
• [x] receiving (follow) undos
• [x] move apHandlers back into apService. Make apService handlers Run before all others. This allows us to e.g. pull objects from create activities
• [x] received notes for trades (accept, update, delete, create)
• [x] add UI in frontend to trigger these actions (treaties, trades)
• [x] fix trade bug
• [x] make Note context support objects, then add context for gameContent key
• [x] add reverse proxy to docker compose setup
• [x] make API Restful make paths be behind /api (for reverse proxy e.g.) check all naming to be restful (e.g. be plural) dont pass IDs in body, rather in path (e.g. trades/id)
• [x] build images for arm
• [x] add instance meta info similar to mastodon: https://docs.joinmastodon.org/methods/instance/

[maybeanerd]

maybe using this lib is an option: https://jsr.io/@fedify/fedify https://fedify.dev/manual/

[maybeanerd]

looks like that didnt work out, it's only for deno

other intersting projects: https://github.com/immers-space/activitypub-express https://github.com/michaelcpuckett/activity-kit

[maybeanerd]

https://github.com/SiranWeb/activitypub-types

[maybeanerd]

Guides

https://socialhub.activitypub.rocks/t/guide-for-new-activitypub-implementers/479

found in the top link, but for quicker access: https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/

[maybeanerd]

https://github.com/digitalbazaar/jsonld.js to use json-LD compaction and stuff

[maybeanerd]

https://swicg.github.io/activitypub-http-signature/

[maybeanerd]

For testing, will finally be released later today https://pubkit.net/

[maybeanerd]

Idea: mark all AP related things as handled/unhandled Once applied( aka the change is reflected in the games Data tables) they are marked as handled and essentially ignored from then on This can also be used to handle worker queues that Go through unhandled activities chronologically

[maybeanerd]

This would mean self-created activities are Always handled when created

[maybeanerd]

Better idea for marking handled: Create an ActivityQueue table All AP activities that are created have an entry there with their ID as FK, and a Type Incoming|Outgoing This way workers can pick up this Queue and either Post activities to other servers, or sync them to the Server state

For now as a POC These workers could Run as cronjobs on the main thread. Later on they could become fully Independent workers. Theoretically even Independent containers

[maybeanerd]

Example of how to use extensions:

https://github.com/w3c/activitypub/issues/313#issuecomment-396652190

https://seb.jambor.dev/posts/understanding-activitypub/

[maybeanerd]

Some context for the outbox:

https://socialhub.activitypub.rocks/t/what-is-an-outbox-really-what-should-be-there-what-should-not/814/2

IMO it should return all activities of the instance actor, supporting pagination of course (and maybe a startFrom Date attribute)

The main goal should be for other instances to backfill actions , e.g. if they were down for a while, or just recently started a treaty.

[maybeanerd]

Ideas for Inbox: Never use actor from Incoming activity ( only it's ID) If it's a new actor, get it and it's Key to validate the request If it's known, validate with the stored key

[maybeanerd]

next TODOs

• [x] Check all occurences of "id: randomUUID" to make sure we don't create AP Things with uuid ids (we definitely do right now). If e.g. activities are missing internalID, add that
• [x] treaty flow (unfollow)
• [x] rework internalID ( Use only for getters of activities and objects. Require them for self-created Things For mapping with game objects, remove on activities. Follow etc doesn't map to treaty, an actorID does. Remove from objects-> Store the APobjectId on the game objects (e.g. trade) instead)
• [x] trade flow (internal changes need to create activities and notes)
• [x] treaty flow <-> following in AP : maybe keep track of followers in addition to treaties: that way we know who to post things to, even if we dont follow them (e.g. a mastodon user following a gameserver)

inbox/outbox handlers

• [x] sending outbox stuff to all followers
• [x] delete outbox things after being sent
• [x] receiving follows
• [x] rework handler to map activities to more specific Things, e.g. undo to unfollow OR unLike. This should streamline downstream handlers
• [x] receiving (follow) undos
• [x] move apHandlers back into apService. Make apService handlers Run before all others. This allows us to e.g. pull objects from create activities
• [x] received notes for trades (accept, update, delete, create)
• [x] add UI in frontend to trigger these actions (treaties, trades)
• [x] fix trade bug
• [ ] add reverse proxy to docker compose setup
• [ ] make API Restful make paths be behind /api (for reverse proxy e.g.) check all naming to be restful (e.g. be singular) dont pass IDs in body, rather in path (e.g. trade/id)
• [ ] add instance meta info similar to mastodon: https://docs.joinmastodon.org/methods/instance/
• [ ] build images for arm
• [ ] look into HTTP signing. finally
• [ ] on outbox posting, target servers better (e.g. follow/unfollow only to the respective servers, as well as likes) Only things that belong to own trades (create, delete) should be shared to all
• [ ] make trade generation in general nicer (e.g. allowing more than one resource)

[maybeanerd]

bug to look into when federating trades:

[maybeanerd]

Seems like this is the issue: https://github.com/maybeanerd/selfhosted-api-trader-game/blob/main/backend%2Fsrc%2Fmodules%2Ftrade%2Ftrade.service.ts#L110

Maybe move the APobject creation to a util just like the Activity creation? To enforce actorIDs being correct

[maybeanerd]

moved some follow up tasks to https://github.com/maybeanerd/selfhosted-api-trader-game/issues/635