forgefed / forgefed

ForgeFed - Federation Protocol for Forge Services

ForgeFed

ForgeFed is an ActivityPub-based federation protocol for software forges. You can read more about ForgeFed and the protocol specification on our website.

Contributing

There's a huge variety of tasks to do! Come talk with us on the forum or chat. More eyes going over the spec are always welcome! And feel free to open an issue if you notice missing details or unclear text or have improvement suggestions or requests.

However, to maintain a manageable working environment, we do reserve the issue tracker for practical, actionable work items. If you want to talk first to achieve more clarity, we prefer you write to us on the forum or chat, and opening an issue may come later.

If you wish to join the work on the ForgeFed specification, here are some technical but important details:

• We don't push commits to the main branch, we always open a pull request
• Pull requests making changes to the specification content must have at least 2 reviews and then they wait for a cooldown period of 2 weeks during which more people can provide feedback, raise challenges and conflicts, improve the proposed changes etc.
• If you wish to continuously participate in shaping the specification, it would be useful to go over the open PRs once a week or so, to make sure you have a chance to communicate your needs, ideas and thoughts before changes get merged into the spec

Important files in this repo to know about:

• The file resources.md lists which team members have access to which project resources, openness and transparency are important to us!
• The actual specification source texts are in the spec/ directory
• JSON-LD context files are in the rdf/ directory

Repo mirrors

• ForgeFed on Notabug
• ForgeFed on Pagure
• ForgeFed on GitHub

Website build instructions

The ForgeFed website is generated via a script using the Markdown files in this repository. See ./build.sh for more details.

License

All contents of this repository are are freely available under the CC0 1.0 Universal (CC0 1.0) Public Domain Dedication.

The ForgeFed logo was created by iko.

Historical resources

ForgeFed started its life on a mailing list. The old ForgeFed forum at talk.feneas.org can be viewed via the Internet Archive's Wayback Machine.

Funding

This project is funded through the NGI Zero Entrust Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.

forgefed's Issues

Excercise in uselessnes

1. This specification is so liveable, that it is not even hosted inside of any project, which could eventually implement it. https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 shows exactly what is the future of such proposal: nothing, because every repository wants to just lock-in their users.

2. Specification is done: GIT-REQUEST-PULL(1). Post its output to a comment box (or send it to the agreed-upon email address) and the server would create a pull request automatically and communicate via email with the original committer. Which leads back to the square one: the problem is not specification, but lack of interest on the side of repositories.

Change the Defaultbranch to 'main'

@bill-auger please change the default branch of this repo to 'main'

It does block mirroring atm

Meta: Self-Assembling Organization

Update: 2019-07

ForgeFed Community Forum

In order to consolidate development and community discussions, there is now a public web forum on the feneas.org website. FeNeAs is a non-profit volunteer organization dedicated to promoting federated networking, such as services and clients using ActvityPub as their federation protocol; and so it is a natural fit for ForgeFed. Everyone is invited to use that forum instead of this GitHub issue tracker or the mailing list for general discussions.

Thanks to FeNeAs for promoting ForgeFed to a primary category and managing the forum.

Web Forum: https://talk.feneas.org/c/forgefed

ForgeFed in the Fediverse

There is also a user on the Mastodon network to which fediverse users can subscribe for progress updates. Feel free to interact with that actor or use hashtag: #ForgeFed on the Mastodon network.

Fediverse: @[email protected] (https://floss.social/@forgefed)

ForgeFed Repository

This GitHub repo has not been updated in some time, and it is unclear at the moment whether or not @yookoala still wants to maintain it. The NotABug repo contains the most recent documentation and reference source code, all currently under the maximally permissive CC0 license.

Repository: https://notabug.org/peers/forgefed

For the time being, that repo is mirrored as a second repo to this github organization:

https://github.com/forgefed/forge-fed

That is still less than ideal of course, as the previous discussions and external links still point to this repo; but i will try to keep that second one in sync for the time being.

---

Update: 2018-06

Notice about Joining the Mailing List

All: I feel that the mailing list is about the right size to have diversify opinions without making everyone crazy. I think I'm going to set some boundaries for later joiner:

If you are a git service software developer, please introduce yourself here and state that you want to join. If nobody in the current mailing list disagree, we'd add you to the mailing list. If not please keep reading our mailing list archive. Should you want to say anything, please follow up existing issues or create new one.

This is only for the sake of discussion quality. If any mailing list member disagree, we may discuss over the mailing list. And if you're not a member, you're welcome to file a new issue in this issue tracker for discussion.

Thanks a lot.

@yookoala
8th June, 2018
(updated 9th June, 2018)

P.S. Prepended to @cjslep original post. The text below the line is the original content.

---

Meta: Self-Assembling Organization

This is going to get a bit meta, but it is just because I am biased to wanting to see success here.

The first part A is kind of an overview of the different moving pieces I see going on, which others may or may not already be aware of. My intention here is to be informative about the state of this space, not dictatorial/authoritative. Part B is just my bland appeal to interested parties in making this successful in a coordinated fashion.

Part A

Just from the various topics I've seen float around, it seems there's several problems to solve, different prioritization in which to solve these problems, different ideas on what those solutions precisely look like, and (obviously) different parties doing these.

What

• Problem of federated authorization: This was talked about in the #social irc some as mentioned in #2
• Problem of fitting Git socialization data into the ActivityStreams data model: Mentioned in #1. Maybe a part of #2, also?
• Problem of fitting Git socialization behaviors into the ActivityPub actor model: Also mentioned in #1. Maybe a part of #2, also?

When

• I've seen suggestions elsewhere of rolling out in two phases: First provide data as ActivityStream objects, then work on the consumption side.
• I've seen some prioritize for solving the federated authorization first.
• The Git socialization features would realistically be implemented piece by piece as well, but no timelines until the design is done.

How

• For federated auth, I've seen IndieAuth and ocap-ld suggested.
• For both Git socialization problems, there's things documented in #1 and #2 already.

Who

• SocialWG: Authored the ActivityStream 2.0 Spec, ActivityStream 2.0 Vocab, also maintains the ActivityStream 2.0 terms list, also authored the ActivityPub spec. As well as many others.
• All the git hosting solution providers: Gitea, Gogs, Gitlab, etc
• Other ActivityPub implementors, such as Mastodon, etc
• (Sorry if I missed you!)
• Peanut gallery w/ biased, vested interest (I fall here).

Why
I had a recent back and forth on Mastodon with a skeptic about this effort, so forgive me for not including this at this time. :)

Hopefully the above is informative!

Part B

I'd love for this effort across projects & people to succeed. I would hate to see people left out of conversations, problems not getting enough visibility, or piecemeal solutions adopted.

I don't have a good solution here; I'm new to the self-organizing open source space. Since I am not a part of the SocialWG nor any of the user-facing projects, I also don't know what the right self-organizing communication structure would look like to get buy-in on decisions from everyone.

Part of this appeal stems from seeing issues like #4, part of it is fueled by my raw excitement. Thanks for reading this long post.

Problem in managing Federated Identity

By @ncoghlan in #6:

I came here to file an issue about handling the federated identity management problem (and noting how difficult that is without authenticated access to email addresses as a federated identifier), but given @cjslep's response above, I think this issue can serve that purpose :)

The first paragraph in the "How it works" section of https://docs.gitlab.com/ee/user/project/import/github.html gives the gist of the problem: in order for repos to map identities correctly, users currently either have to make their email addresses on each service public, or else authenticate with the importing service before the import happens.

Neither GitLab nor anyone else currently models the notion of an "unclaimed pseudonym" to track activity where a user ID on a remote service is known, but that remote identity isn't yet mapped to a local identity in a way that verifies that the same human is plausibly in control of both accounts.

Add @techknowlogick to Working Group

Hi,

I'm @techknowlogick, a contributor and one of several maintainers of Gitea. Please check https://github.com/go-gitea/gitea/blob/master/MAINTAINERS for verification. While I can't speak on behalf of the project, federation is a topic that I am personally interested in and would like to be a part of the conversation.

Thanks,
@techknowlogick

No fediverse IDs on the ReadMe page on this repo

I want to flick you a couple of quick links. Looked for some fediverse accounts on the ReadMe page so I didn't have to annoy you by opening an issue, but I couldn't find any so ...

Had an interesting chat today with Drew DeVault, developer of Sr.Ht (https://sr.ht/), and a few other drive-by commenters. Started here:
https://niu.moe/@Wolf480pl/100320867300504833

Mostly pretty circular, but there was some discussion of specific use cases for a tool like GitPub, and a few potentially helpful posts about where the email-based functionality built into Git might be more useful than the AP protocols. Like:
https://cmpwn.com/@sir/100328515339900975

specification format

Im asking myself in what format the specification should be delivered.

Will it be something like a rfc?
https://tools.ietf.org/html/rfc7033

Could it be something like swagger?
Would be quite nice, as it allows to generate all the sdks
https://github.com/Chocobozzz/PeerTube/blob/develop/support/doc/api/openapi.yaml

go-ap: codified conceptualisation

I personally like to conceptualise by writing code. That's why quickly built a low level library in golang. It allows you compose, decode and encode ActivityPub objects.

Next Im going to build a lite microservice, implementing the basic ActivityPub endpoints.
That allows to tinker around with the communication layer and to extend it with the git specific types.

https://github.com/21stio/go-ap

Can we have moderation and blocking ideas built into this?

I think that these should be in the specifications in order to help with moderation tools in the applications themselves.

I think that at a minimum we should have definitions of how to handle when one server doesn't want to hear anything from another server (so on the sending side what behaviour is required when there is no response, or a connection is refused and on the receiving side this should be allowed)

I am sure that there are other times, like handling specific identities on a server.

It is certainly something I would appreciate on GitHub and something like this is going to need moderation tools of some sort.

ask w3c/activitypub how to extend the activitypub protocol

maybe it would be a good idea to ask the activitypub authors for general guidelines on how to extend the protocol, to make sure it won't end in a big mess

Typo in the repository description: extenstion → extension

The title says it all :)

Git is Already Federated & Decentralized

The following blog post mentions ForgeFed.

https://drewdevault.com/2018/07/23/Git-is-already-distributed.html

Forgefed videoconference - June 13th 2pm UTC

there has been renewed interest in forge-fed recently by forge developers and other related projects from the forge-friends group - an online conference is planned to discuss future development, infrastructure, and management of forge-fed - as always, the community is invited to participate

Location: https://meet.jit.si/ForgefedMeeting
Date: June 13th 2pm UTC
Details: https://forum.forgefriends.org/t/forgefed-videoconference-june-13th-2pm-utc/715

Why am I being ostracized?

If you are experienced in writing specifications, you're also welcome to join the effort.

So if I have no experience, I am not welcomed in this project and barred from getting the experience?

ActivityStream extension process

If we agree to extend ActivityPub for git federation, we'd need to specify the context on how we'd add vocabs to the ActivityStream.

The ActivityPub community group is drafting an extension process.
Things are still under discussion and we'll have to wait for the finalized version.
https://github.com/w3c/activitystreams/wiki/Extension-process

Based on the current draft, this is probably what we have to do in the development process:

Multiple-implementation extensions still in development

For when we're experimenting with new problem areas that need new vocabulary terms, but we're not quite sure about them yet. For these, we should:

• Declare it with a Github issue

• use some kind of sub-namespace of AS2 (https://www.w3.org/ns/activitystreams/dating# or https://www.w3.org/ns/activitystreams#dating?)

• Implementors use the namespace in their contexts and the namespaced values in their documents:

   {
       "@context": ["https://www.w3.org/ns/activitystreams/",
       {"dating": "https://www.w3.org/ns/activitystreams/dating#"}],
       "type": "Person",
       "dating:seekingGender": "any",
       "dating:geographicalRestrictions": {
           "dating:within": "50km",
           "dating:of": "https://places.example/New_York_City"
       }
   }

Federated issue tracking

Problem

1. Ken on server A created an issue to Lennon's repository on server B.
2. Mandy on server B is a contributor to Lennon's repository.
3. Oprah on server C is also a contributor to Lenonn's repository.
4. Who should have the permission to close the issue? And how?

@tantek has experience on Github bridging. And he has some insight about cross domain permission handling. He raised interesting point in the ActivityPub community group meeting tonight that lead me thinking of this problem. (I think @cwebber tried to raise the same point but I was too stupid to pick up.)

The same problem also applies to a PR. Do we handle it? Or do we omit it?

User stories

This issue is open for non-mailing list users to be able to contribute user stories.

Please see this wiki page and this mailing list thread for information. Post user stories below in comments.

Let's move to somewhere outside of GitHub

Why the hell is this project hosted on GitMShub?

Protected branches

Let's say there's a branch with an ACL, so only the specified servers could checkout it and only specified users could push to it. How would that look?

HN post

please upvote, to create some awareness

https://news.ycombinator.com/edit?id=17245072

Instance closure protection

I missing a 'Instance closure protection' point. How the protocol should handle stuff on cases where a instance (unexpectedly) shuts down. There is otherwise a great risk many projects, especially inactive, that would likely get lost in such an event. Some kind of archiving would be desirable.

This would introduce some other complexities. Like how to handle when you want to delete or move a repo.

Still "maintained"?

As it has been seen in #24 and #26 this repo seems to be dead.

So can someone please archive this repository, to mark it as unmaintained. People then cannot submit PRs and there is a big warning that this is archived.
Remember to add a note to the Readme before to explain that it is unmaintained, and – if you think this is useful – why and probably mention alternatives.

If this is not possible, we can at least reflect the status in this issue or so.

Need to provide a baseline specification

The baseline specification would need to support:

• Pull Request
• Forking

Which implies specification to the Actors involve:

• Person
• Repository
• Branch

Terms

Git Service: Web based Git service like Gogs, Gitea, Gitlab, Pagure.
Web Repository: Web based entity on a Git Service that represents an underlying Git repository branch.
upstream: A git repository where a PR is being sent TO.
downstream: A git repository where a PR is being sent FROM.

Features

For federation, these are the base line features:

1. Allow user to create a Pull Request to a remote upstream Web Repository.
2. Allow an upstream Web Repository to receive a Pull Request from a downstream Web Repository.
3. Allow a downstream Web Repository to report updates (e.g. git push) of a branch to an upstream Web Repository that it previously sent Pull Request to.
4. Allow an upstream Web Repository to notify a remote Git Service that a Pull Request is commented, tagged, assigned, reviewed, closed, re-openned or otherwise updated.
5. Allow user to create a Fork notification to a remote upstream Web Repository.
6. Allow an upstream Web Repository to receive a Fork notification from a downstream Web Repository (not branch specific).
7. Allow any agent to subscribe to any Web Repository updates.

Based on these feature needs, It might also be essential to allow any Web Repository (specific branch) to be properly addressable and discover-able by query protocol (e.g. Like how Mastodon use Web Finger). This universal address should be differ from user or organization.

Related Issues

There are several issues in different software repository of the same topic:

• gogs/gogs#4437
• go-gitea/gitea#1612
• https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

Define a project commit format

GAnarchy has this thing called a "project commit". It uses the following format:

[Project] {{Title}}

{{Description}}

Title may not contain newlines and Description may contain anything. However, I don't feel like it's worthwhile to keep it GAnarchy-specific. As such, I'd like to propose a common project commit format that anything can use. It would still follow the same basic structure, but we can adapt some things. We could add an YAML section or something, or define the description to be markdown-based, or so on. Maybe it should also be allowed to refer to any files available at the moment of the project commit, which would be useful for a project logo. This would benefit any tools doing anything even remotely like GAnarchy. I'd need to adapt GAnarchy to handle the new format, but if we stick to plaintext formats, it shouldn't be a big deal.

Current Status of ForgeFed - README!

I was wondering what the current status of this project is. I see that there is a beta specification and a long discussion on the mailing list, but I don't see activity after Aug-Sept 2018. Is work still ongoing? Are there any reference implementations?

GAnarchy - "federated" (not sure if right term) git-based projects

Please take a look at these:

1. https://ganarchy.github.io/
2. https://ganarchy.autistic.space/
3. https://cybre.space/tags/gan385e734a52e13949a7a5c71827f6de920dbfea43