a/website
1
2
Fork 1
Code Issues Pull requests Projects Releases Wiki Activity

Add note about OCAPs

Browse source
This commit is contained in:
Anthony Wang 2023-12-27 22:24:34 +00:00
parent 318813636a
commit 258ad1ec93
Signed by: a
SSH key fingerprint: SHA256:B5ADfMCqd2M7d/jtXDoihAV/yfXOAbWWri9+GdCN4hQ
1 changed files with 2 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/posts/forge-federation-design-discussion.md
View file

@ -20,3 +20,5 @@ The other big problem is *what* to synchronize. I've had multiple people tell me
Now at first you might think that's a terrible idea, but here me out. Forgejo currently stores issues and stuff in its database, so we can continue doing that and expose them as JSON at some API endpoints. In addition, any programming language can easily process JSON, which is ideal because the purpose of ForgeFed is interoperability. Finally, JSON also makes it easy to selectively sync stuff. For instance, say Bob wants to open an issue on Alice's project on a different instance. Then we really only need to synchronize that single issue thread between the two instances instead of the entire project, which could be gigantic. Sure, you could probably do the same with git subtrees or something, but this idea is way easier. Another small benefit of using Activity Streams is that ForgeFed can be interoperable with other ActivityPub software, so you can do things like star a repository using your Mastodon account. So how do you actually sync JSON? What about conflict resolution? Well, the nice thing is that with primary-secondary resolution, we don't need conflict resolution. The primary server is always correct, so we can overwrite data on the secondary server with stuff from the primary server.
There are actually two different JSON formats right now for representing forge data, [F3](https://f3.forgefriends.org/) and the [representation in ForgeFed](https://forgefed.org/spec/#actor-and-resource-representation), but I'm going to work on merging those two into a single specification this month.
One last thing: what about [object capabilities](https://forgefed.org/spec/#object-capabilities)? I haven't really thought too much about this, but I think they aren't necessary for Forgejo at least. Any activity by a user is signed with HTTP signatures, which provides some security. For more complicated scenarios, we probably need OCAPs, but I'm going to work on other stuff first.