Skip to content

forgefed/forgefed

main
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
3 branches 0 tags
Code

Latest commit

fr33domlover and fr33domlover Vocabulary & Modeling: Add the Project type (#163)
71c70d4 Nov 5, 2022
Vocabulary & Modeling: Add the `Project` type (#163) 
The `Project` type is a way to group and nest forge/FSDL component
actors, e.g. Repository, TicketTracker, PatchTracker, etc. for several
purposes:

- Covenient grouped display in UI when browsing, exploring, searching
- Easy management for project team members
- Possibility to grant/delegate OCAPs to a whole projecr rather than do
  it individually to every component, which is cumbersome and messy

Properties `components` and `subprojects` are added as well.

Q1: Why isn't Project a subtype of the AS2 Group?

A: ActivityPub doesn't define any behaviors for Group, so the main benefit of this would be to share behavior with usage of Group on the Fediverse. This can be advantage (if the behaviors are aligned) but can also cause problems (if the behaviors conflict). I know people are doing group related things on the Fediverse, but I'm not personally aware of something established, so I prefer to protect us from conflicts for now. At any point, if it becomes helpful, we can make Project extend Group.

Q2: Why use a custom property `subprojects` for children, but the AS2 `context` for parents?

A: Because there's no good match for the children property in AS2 (I also looked at some RDF ontologies but couldn't find anything that really felt right). I'm considering to use a custom property for parents too, just for consistency, but not sure. `context` should work.

Q3: Why does `subprojects` map to a `Collection` while `context` just lists parents without a `Collection`?

A: There aren't clear guidelines for when to use a `Collection`, when to use an RDF `List` and when to use a simple multiple-values-for-a-property, but I'm observing a pattern that's used in AP, e.g. with `replies` and `inReplyTo`, and which makes sense to me:

In a nested structure where parents have the authority about who their children are (because they provide them some service), and where parents can have many children but children have few parents,

- the parents list the children using a `Collection` that can be paginated and items can be added and removed,
- while the children, mostly just for information, list the parents they have and whose services they use.

Parent projects provide a service to subprojects: They delegate access-to-them to relevant teams and people. And projects can have many children, but probably few parents, probably just 1 in mose cases. So, it fits the case described above. It also works the same with ForgeFed's ticket dependencies, for a similar reason.

Co-authored-by: fr33domlover <fr33domlover@riseup.net>
Reviewed-on: https://codeberg.org/ForgeFed/ForgeFed/pulls/163
Reviewed-by: Aravinth Manivannan <realaravinth@noreply.codeberg.org>
71c70d4

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
.woodpecker
 
 
doc
 
 
html
 
 
rdf
 
 
spec
 
 
.gitignore
 
 
COPYING
 
 
README.md
 
 
build.sh
 
 
deploy.sh
 
 
resources.md
 
 
ForgeFed - Federation Protocol for Forge Services How does it work? So how do I use it? What's the status? Where do I talk with you and ask questions? How can I contribute? Repo mirrors Website build instructions License Historical resources

README.md

ForgeFed - Federation Protocol for Forge Services

Get it on Codeberg

ForgeFed is a federation protocol for software forges and other web services dealing with version control repositories, project tracking and other aspects of the software development lifecycle and ecosystem. This includes repository hosting websites, issue trackers, code review management applications and more.

Federation means that these websites can interact, allowing the humans using them to interact too, despite being registered on different websites. For example, imagine you could host your Git repos anywhere you want, perhaps even your own personal website, but still be able to open issues and submit pull requests against other people's repos hosted elsewhere, without having to create accounts on those other websites!

Without federation, we end up having to choose between:

  • Centralizing into huge profit-oriented websites, where we're powerless
  • Hosting our code on a small website where we're in control and freedom but isolated from the community

With federation, all the websites now communicate with each other to form a network and community of collaboration in which we're all both free and connected. It puts the power back into our hands to create tools and collaborate in ways that are aligned with human needs, powerful and safe ways that allow us to include everyone and that don't depend on some big company's policies or some website suddenly shutting down. Let's create the future together!

How does it work?

ForgeFed is an ActivityPub extension. ActivityPub is an actor-model based protocol for federation of web services and applications.

It's a bit like e-mail, except the data sent is JSON objects (i.e. structured computer-readable data), and not only humans have inboxes where they can be contacted, but also repositories and issue trackers have inboxes through which they can be remotely and safely interacted with.

On top of ActivityPub's vocabulary (common language for websites to use for communicating) and protocol, ForgeFed defines new vocabulary terms related to repositories, commits, patches, issues, etc. and the protocol for creating and interacting with such objects across servers.

So how do I use it?

ForgeFed is a protocol, i.e. instructions for how websites can communicate with each other. For forge federation to really happen, we need to code it into forge software. This is still in progress, but there are demos and prototypes you can play with if you're curious :-) See below for ways to get updates on the latest work on this.

What's the status? Where do I talk with you and ask questions?

The ForgeFed protocol specification is on the website. The website is generated from the Markdown sources found in this repository. There are links there to Matrix and IRC chat, our forum, issue tracker, list of ForgeFed implementations and their status, and more. You can also follow our progress on the fediverse.

Come talk with us :-)

How can I contribute?

There's so much variety of tasks to do! Come talk with us on the chat/forum.

More eyes going over the spec are always welcome! And feel free to open 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 master 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.
  • So 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

This repo is mirrored at:

Website build instructions

./build.sh

License

All artifacts produced by the ForgeFed work-group are freely available under the CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. All contributions to the wiki must also be offered freely as such.

The ForgeFed logo was created by iko.

Historical resources

ForgeFed started its life on a mailing list, here's the archive.

The ForgeFed forum, now at a new location, used to be at talk.feneas.org, the old forum and posts can be viewed via the Internet Archive's wayback machine.

About

ForgeFed - Federation Protocol for Forge Services

forgefed.org

Topics

git forge distributed vcs federation scm federated activitypub

Resources

Readme

License

CC0-1.0 license

Stars

926 stars

Watchers

115 watching

Forks

12 forks

Contributors 9

Languages