Delete the old example from FEDERATION.md

This commit is contained in:
Anthony Wang 2022-06-21 11:34:16 -05:00
parent e090c95c17
commit 24a462a95d
Signed by: a
GPG Key ID: BC96B00AEC5F2D76
3 changed files with 15 additions and 12 deletions

View File

@ -45,15 +45,3 @@ When opening a pull request to a remote repository, the pull request can be rend
## Migrations
If you change your username or the name of repository, Gitea handles this similarly to how Mastodon does. Gitea will send a `Move` activity to your followers and update your actor to point to the new actor.
## Example
Aviva has an account on Gitea instance dev.example and Luke has an account on Gitea instance forge.example. Luke would like to create an issue on Aviva's Game of Life repository at dev.example/aviva/game-of-life. First, he clicks the `New Issue` button at the Game of Life repository. Since Luke does not have an account on dev.example, a pop-up box appears asking him to type in his instance, forge.example. He is redirected to forge.example/aviva@dev.example/game-of-life, where he can now create a new issue normally. Once he finishes creating the issue, his instance sends a `Create` activity to the dev.example/aviva/game-of-life actor, which creates the new issue on dev.example as well.
Next, Aviva replies to Luke's issue from her own instance. This sends a `Create` activity to forge.example, and the comment is created on Luke's instance.
I was writing an example scenario for the FEDERATION.md file and have ran into a problem. Let's say we have three people, Alice, Bobert, and Charlie. Alice and Bobert are on different instances and Bobert would like to create an issue on one of Alice's repositories. When he tries to create the issue on Alice's instance, he is redirected to his own instance, where the remote repo is rendered and he can create the issue. Once he finishes creating the issue, his instance sends a `Create` activity back to Alice's instance. So far no problems. However, what if Charlie then creates an issue on Alice's repository, how does Bobert's copy of the repo on his own instance know about Charlie's new issue?
If Bobert is a collaborator on Alice's repo, there's no problem because Alice's repo will send updates out to everyone in the repo's `Team` collection. However, if he is not, then when Bobert views the list of issues of the remote repo on his own instance, his instance will have to send out a request to fetch all the issues open on Alice's repo. OK, so that's not too bad either.
The real problem is supporting things like issue search on Bobert's instance.

5
go.work Normal file
View File

@ -0,0 +1,5 @@
go 1.18
use .
replace github.com/go-ap/activitypub => /home/ta180m/Code/activitypub

10
go.work.sum Normal file
View File

@ -0,0 +1,10 @@
github.com/cespare/xxhash v1.1.0 h1:a6HrQnmkObjyL+Gs60czilIUGqrzKutQD6XZog3p+ko=
github.com/cpuguy83/go-md2man v1.0.10 h1:BSKMNlYxDvnunlTymqtgONjNnaRV1sTpcovwwjF22jk=
github.com/go-ap/errors v0.0.0-20220615144307-e8bc4a40ae9f h1:kJhGo4NApJP0Lt9lkJnfmuTnRWVFbCynY0kiTxpPUR4=
github.com/go-ap/errors v0.0.0-20220615144307-e8bc4a40ae9f/go.mod h1:KHkKFKZvc05lr79+RGoq/zG8YjWi3+FK60Bxd+mpCew=
github.com/go-ap/jsonld v0.0.0-20220615144122-1d862b15410d h1:Z/oRXMlZHjvjIqDma1FrIGL3iE5YL7MUI0bwYEZ6qbA=
github.com/go-ap/jsonld v0.0.0-20220615144122-1d862b15410d/go.mod h1:jyveZeGw5LaADntW+UEsMjl3IlIwk+DxlYNsbofQkGA=
github.com/go-redis/redis v6.15.9+incompatible h1:K0pv1D7EQUjfyoMql+r/jZqCLizCGKFlFgcHWWmHQjg=
github.com/klauspost/cpuid v1.3.1 h1:5JNjFYYQrZeKRJ0734q51WCEEn2huer72Dc7K+R/b6s=
github.com/pierrec/lz4 v2.0.5+incompatible h1:2xWsjqPFWcplujydGg4WmhC/6fZqK42wMM8aXeqhl0I=
github.com/russross/blackfriday v1.5.2 h1:HyvC0ARfnZBqnXwABFeSZHpKvJHJJfPz81GNueLj0oo=