Forgejo started implementing it but it's very far from being useful in practice yet. A lot of work needs to be done first[1], might take years, I guess.
It all depends on interest from the developer community. Many devs are rooting for forge federation for years and are waiting for it to happen. Both Forgejo [0] and ForgeFed [1] are fully community-driven free software efforts, and things go as fast as there are people stepping up to do the work.
The ActivityPub-related [2] epic at Gitlab [3], which I also linked in another comment, is another example. It is a ramp up to adding support for the ForgeFed protocol extension. Gitlab has mentioned they do not give high priority to the issue, but will leave it open for community contribution. At one point implementation-wise things went very fast here, until people involved got other duties.
For everyone who'd love to see the fragmented landscape of separate self-hosted code forges become inter-connected and offer similar FOSS project discovery experience as Github: You can help make that a reality.
Edit: I should of course also mention Codeberg [4] which runs Forgejo on their servers with some additional facilities for scaling to support their big community. An example where a centralized community hub starts to shape which may one day become a real competitor to Github (where it comes to hosting FOSS repo's).
Okay, so this is actually GitHub's mastodon. I'm down. Honestly, i was just thinking of moving to Gitlab because I have a feeling GitHub might start being terrible soon.
Gitlab is a monster to host for your own small amount of projects. If I where to start fresh I would go with https://forgejo.org/
I am also a bit worried how gitlab has changed its pricing not so long ago and the clear push to go towards maximum profit regardless if it's users are still getting a good product.
I use GitLab for essentially everything and I haven't noticed anything get worse. It's constantly getting new features and many of them are very enterprise-focused, but they don't make the everyday user's experience worse, you can mostly just ignore them.
Indeed. But all the work done before that are community contributions. They reopened to allow that kind of work to continue. If there's enough community interest, then Gitlab will become a federated forge most likely.
Also see tangled.sh, which is GitHub's BlueSky (built on ATProto). It's much less mature as a forge than the ones that are being adapted for ForgeFed, but the social support is already very useful in a way that no forge that wants to implement ForgeFed is yet.
This is the dream right? Self host all your repos but still have contact with the community. The other alternative forges like forejo are cool but feel like simply turning the clock back on GitHub.
I think you are mixing things up.
Forgejo is one of the soon implementing, self-hostable software forges and one of the 3 listed implementations.
Codeberg is the (Github-alike) central forgejo server, where the team develops and which is also available for general open source coding needs. ForgeFed issues are tracked on Codeberg, so they already show their interest.
I still believe that it'd be easier to add better tooling to the already existing email integration. Nothing is stopping a desktop app to allow users to easily set up git+email and view/comment/preview/apply patches in a clean and easy-to-use interface.
Activitypub just brings so much complexity. Activitypub works best when you're not using it like a website but rather have a dedicated "activitypub" client. Otherwise you'll visit a repo, try to add a pr/issue/etc, it will ask you to sign in to your instance. You'll be redirected, sign in and then see the same repo but on your instance where you can then do the operations. The whole UX is just really confusing.
Any new forge that wishes to partake in this social network also has a massive task ahead of it, because creating an activitypub integration is a lot of work. It's not easy.
Most importantly, people are already signed up to email, so the account signup part is already done too.
You are correct. Someone posted about Radicle here a couple days ago[1] and went down that rabbit hole. The user docs say that their p2p network draws inspiration for Secure Scuttlebutt's gossip protocol.
I'm not 100% sold on federation / activitypub in its current state. I think p2p is far more interesting. With Radicle, you don't have to run a server (which, if Mastodon is anything to go by, is a lot of overhead). So anyone can try it! Radicle is ready to use right now.
> 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
Yes, yes, yes, yes!!!! This would be a huge boost for everyone. I'm sure I'm not alone in disliking github, but begrudgingly using it quite a lot[0] because realistically, the alternatives create barriers to entry for a lot of people.
I think this will take a long time to catch on, but hopefully in several years time, the point where all the world's open source projects were beholden to a single tech giant will seem like a strange footnote.
[0] I've shifted a lot of projects to codeberg, but still mirror them all to github.
And if you just need a great forge for your company's dev teams you are all good to go. OTOH if you self-host a popular FOSS project then all of the network effects of hosting your repo on Github are gone. If you are a quite large project, such as Fedora who chose Forgejo [0] then it is fine to have a dedicated forge. If your small library repositories are hosted on single-person or small community self-hosted instances, then there is a lot of benefit if the forges hooked into this larger software development social network.
There are a couple more among public Forgejo instances [0]. For instance, though it is not very clear what they offer exactly, CodeFloe [1] mentions priced tiers in their FAQ.
> The priced tiers only exist to cover additional hardware costs of individual users which require extended resources for storage and CI/CD (CPU/Mem) in a transparent manner.
Sadly, as soon as I open the site in a private window with access to Notifications denied, a full page error screen about "Odoo Client Error" appears asking you to report... something.... to someone...? Not a good look at all.
I hope ActivityPub is the right protocol for this.
I have been using Mastodon for a couple of years now and frequently can't access media which is more than a couple days old from other servers, and I see only a subset of the replies, toots and stars...
The media issue has nothing to do with the protocol itself, and everything to do with servers that choose to expire remote content.
The "subset of the replies" issue likewise isn't inherent, but is somewhat more problematic as it requires everyone to behave in ways that makes it work, e.g. push replies back to the origin server, and regularly poll the origin for additional replies etc., and Mastodon itself is not great at his.
To the extent AcitivityPub itself is affecting any of it, it's only in the sense that ActivityPub imposes very few constraints on implementations, and that leaves a lot of room for specific applications to behave in counter-productive ways..
A problem I've seen emerge in the Lemmy side of ActivityPub is that it relies on a hub and spoke model. In practice this has failed when the hub goes offline, all the spokes are now left with independent copies of it's last known state and destroys the community progress (have to rebuild elsewhere, lose old content and references, etc.) if even you can regrow the community.
Mastodon has the similar problem but worse with content discovery; a user is not "seen" remotely by anyone until one remote person finds them and subscribes to their content explicitly. On every single remote instance, which of course is undesirable but that's how ActivityPub is designed.
I don't believe in ForgeFed terms this matters as much as being able to search across the federated network for repos, etc. which I think is a key feature. Sure issues and user accounts and whatnot, but an AP-linked FF-wide search would be insane on how useful it could be for users (and how to implement a "distributed search index" seems like a tough nut to crack).
A search is pretty "easy" (doing it distributed is just more expensive in terms of resources than a single index, because you end up doing multiple searches in parallel and merging results) - the main issue with search on the Mastodon side of things have been politics. That is, a lot of people like that discovery isn't as easy as searching. For subsets of the Fediverse where people actually agree search is a good thing or if the software specifically indicates consent or not, it'd be fairly straightforward to provide.
For Lemmy the hub and spoke model is essentially intentional - groups "belong" to a specific instance. But there's nothing in ActivityPub that'd prevent a USENET style model of groups either. There's nothing in ActivityPub that prevetns an application where a collection is effectively open to writing by all, and that would then relay messages to a sufficient set of "downstream" instances.
It'd be interesting to have that as an alternative to the Lemmy approach - I think the two could live quite well side by side.
> because you end up doing multiple searches in parallel and merging results
This reminds me of the design model of SearX/SearXNG - instead of a distributed forge index, it would distribute the search endpoints of forge instances to facilitate the next steps you outline. It almost feels like a central coordinator or maybe a CDN-like network set of search proxies would be needed to do the actual combining and filtering of results. Maybe it could fit in the Codeberg operational umbrella in some future plan.
In practice Nostr does this step on the client side - one subscribes to relays, then when querying for new content it asks all relays, gets all the duplicate metadata and filters on the client. Huge network use and battery drain on your handheld device, Nostr bouncers have emerged for this exact same reason, a popular software is "Bostr", easy to find examples run by random volunteers but it requires money (disk/cpu/ram): https://bostr.azzamo.net/
There are quite a lot of approaches you can take to reduce the cost of this, e.g. sharding by search term, so the number of shards hit for any specific search term is a subset of the total set.
You can also certainly broadly cache the "top" of the hit lists for very common searches, so you don't need to fan out unless you're doing less common searches or going beyond the first "page" of results.
Is AP the "right protocol", well, we shall see. i happen to think that, not so different from, say, smtp or imap, while AP does have some issues, i think AP will be *good enough*. I say, good enough, in order to get started, to get momentum...once that happens, then yes, things can be optimized...and by then the value of federation for things like code forges will be obvious, and then the next phases will be more about optimization - both technical and otherwise.
It doesn't feel to me as if the author of that really get AP.
AP fundamentally rests on exchanging activities, that model operations on objects in collections.
Everything under their "basic concepts" section can map cleanly to an application that speaks AP.
AP has actors. Methods maps to Activities. Making networking transparent is down to wrapping things in a local framework that chooses when to use networking. Their concept of "vats" similarly is down to a lcal framework that calls method if local and posts AP activities otherwise.
AP provides a format for storing both the activities and other objects to disk, but you can choose to use your own, and that includes state that might reference other actors.
I'm working on an app server, in fact (not open source) that is based around those concepts and provides all of the things they're describing, but currently with AP as the main external protocol (that is likely to change - e.g. we're likely to use NATS for communication internally in clusters of these app servers).
Is there any server actually using this so one can see it in action? They only seem to list Vervis, but the linked https://vervis.peers.community/ is down.
Last obvious activity on the spec/issue tracker is a month ago (fairly recent), blog six months ago, forum a year ago. Sounds alive, but not particularly active.
See my other comment at https://news.ycombinator.com/item?id=44896910 .. community involvement determines progress. Especially since the goal is to mature open standard specification for the ActivityPub protocol extension there is a chicken/egg. The spec has most chance to become successful if there are early adopters who embrace the vision of forge federation.
Forgejo started implementing it but it's very far from being useful in practice yet. A lot of work needs to be done first[1], might take years, I guess.
[1] https://codeberg.org/forgejo-contrib/federation/src/branch/m...
It all depends on interest from the developer community. Many devs are rooting for forge federation for years and are waiting for it to happen. Both Forgejo [0] and ForgeFed [1] are fully community-driven free software efforts, and things go as fast as there are people stepping up to do the work.
The ActivityPub-related [2] epic at Gitlab [3], which I also linked in another comment, is another example. It is a ramp up to adding support for the ForgeFed protocol extension. Gitlab has mentioned they do not give high priority to the issue, but will leave it open for community contribution. At one point implementation-wise things went very fast here, until people involved got other duties.
For everyone who'd love to see the fragmented landscape of separate self-hosted code forges become inter-connected and offer similar FOSS project discovery experience as Github: You can help make that a reality.
Edit: I should of course also mention Codeberg [4] which runs Forgejo on their servers with some additional facilities for scaling to support their big community. An example where a centralized community hub starts to shape which may one day become a real competitor to Github (where it comes to hosting FOSS repo's).
[0] https://forgejo.org
[1] https://forgefed.org
[2] https://www.w3.org/TR/activitypub/
[3] https://gitlab.com/groups/gitlab-org/-/epics/11247
[4] https://codeberg.org
Okay, so this is actually GitHub's mastodon. I'm down. Honestly, i was just thinking of moving to Gitlab because I have a feeling GitHub might start being terrible soon.
Gitlab is a monster to host for your own small amount of projects. If I where to start fresh I would go with https://forgejo.org/
I am also a bit worried how gitlab has changed its pricing not so long ago and the clear push to go towards maximum profit regardless if it's users are still getting a good product.
I use GitLab for essentially everything and I haven't noticed anything get worse. It's constantly getting new features and many of them are very enterprise-focused, but they don't make the everyday user's experience worse, you can mostly just ignore them.
At Gitlab there is this epic working on ActivityPub support:
https://gitlab.com/groups/gitlab-org/-/epics/11247
They are not going to do anything about it.
The issue was closed last month. Some vocal people complained, then the PM reopened but made it clear that federation is not their priority: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_2603...
Indeed. But all the work done before that are community contributions. They reopened to allow that kind of work to continue. If there's enough community interest, then Gitlab will become a federated forge most likely.
Also see tangled.sh, which is GitHub's BlueSky (built on ATProto). It's much less mature as a forge than the ones that are being adapted for ForgeFed, but the social support is already very useful in a way that no forge that wants to implement ForgeFed is yet.
This is the dream right? Self host all your repos but still have contact with the community. The other alternative forges like forejo are cool but feel like simply turning the clock back on GitHub.
I think you are mixing things up. Forgejo is one of the soon implementing, self-hostable software forges and one of the 3 listed implementations.
Codeberg is the (Github-alike) central forgejo server, where the team develops and which is also available for general open source coding needs. ForgeFed issues are tracked on Codeberg, so they already show their interest.
Given github's reliability trend, maybe turning the clock back isn't such a bad thing...
Self host on my phone.
Automatic replication so that 3 copies are always available through the network, even in 50 years.
I still believe that it'd be easier to add better tooling to the already existing email integration. Nothing is stopping a desktop app to allow users to easily set up git+email and view/comment/preview/apply patches in a clean and easy-to-use interface.
Activitypub just brings so much complexity. Activitypub works best when you're not using it like a website but rather have a dedicated "activitypub" client. Otherwise you'll visit a repo, try to add a pr/issue/etc, it will ask you to sign in to your instance. You'll be redirected, sign in and then see the same repo but on your instance where you can then do the operations. The whole UX is just really confusing.
Any new forge that wishes to partake in this social network also has a massive task ahead of it, because creating an activitypub integration is a lot of work. It's not easy.
Most importantly, people are already signed up to email, so the account signup part is already done too.
What if pull requests are accepted via a Delta Chat channel? Reusing chatmail infrastructure to deliver .patch files essentially.
Previously:
ForgeFed - https://news.ycombinator.com/item?id=37362088 - Sept 2023 (63 comments)
Git-bug [0] added request for ForgeFed-based federation support to Triage last April [1].
[0] https://github.com/git-bug/git-bug
[1] https://github.com/git-bug/git-bug/issues/172
Could be similar: https://tangled.sh
Tangled is cool, but it makes me long for the good old days when we had git-ssb: https://git.woodbine.nyc/cel/git-ssb
Isn't radicle quite similar? https://radicle.xyz/
You are correct. Someone posted about Radicle here a couple days ago[1] and went down that rabbit hole. The user docs say that their p2p network draws inspiration for Secure Scuttlebutt's gossip protocol.
I'm not 100% sold on federation / activitypub in its current state. I think p2p is far more interesting. With Radicle, you don't have to run a server (which, if Mastodon is anything to go by, is a lot of overhead). So anyone can try it! Radicle is ready to use right now.
[1] https://news.ycombinator.com/item?id=44874945
and tangled supports jujutsu change-ids.
> 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
Yes, yes, yes, yes!!!! This would be a huge boost for everyone. I'm sure I'm not alone in disliking github, but begrudgingly using it quite a lot[0] because realistically, the alternatives create barriers to entry for a lot of people.
I think this will take a long time to catch on, but hopefully in several years time, the point where all the world's open source projects were beholden to a single tech giant will seem like a strange footnote.
[0] I've shifted a lot of projects to codeberg, but still mirror them all to github.
Ya sure whatever. Forgejo is already awesome, just give me a host I can pay for enterprise support
And if you just need a great forge for your company's dev teams you are all good to go. OTOH if you self-host a popular FOSS project then all of the network effects of hosting your repo on Github are gone. If you are a quite large project, such as Fedora who chose Forgejo [0] then it is fine to have a dedicated forge. If your small library repositories are hosted on single-person or small community self-hosted instances, then there is a lot of benefit if the forges hooked into this larger software development social network.
[0] https://communityblog.fedoraproject.org/fedora-chooses-forge...
Talk to https://www.codey.ch/.
There are a couple more among public Forgejo instances [0]. For instance, though it is not very clear what they offer exactly, CodeFloe [1] mentions priced tiers in their FAQ.
> The priced tiers only exist to cover additional hardware costs of individual users which require extended resources for storage and CI/CD (CPU/Mem) in a transparent manner.
[0] https://delightful.coding.social/delightful-forgejo/#public-...
[1] https://codefloe.com/
Sadly, as soon as I open the site in a private window with access to Notifications denied, a full page error screen about "Odoo Client Error" appears asking you to report... something.... to someone...? Not a good look at all.
Screenshot: https://postimg.cc/WFDzQndC
I hope ActivityPub is the right protocol for this.
I have been using Mastodon for a couple of years now and frequently can't access media which is more than a couple days old from other servers, and I see only a subset of the replies, toots and stars...
The media issue has nothing to do with the protocol itself, and everything to do with servers that choose to expire remote content.
The "subset of the replies" issue likewise isn't inherent, but is somewhat more problematic as it requires everyone to behave in ways that makes it work, e.g. push replies back to the origin server, and regularly poll the origin for additional replies etc., and Mastodon itself is not great at his.
To the extent AcitivityPub itself is affecting any of it, it's only in the sense that ActivityPub imposes very few constraints on implementations, and that leaves a lot of room for specific applications to behave in counter-productive ways..
A problem I've seen emerge in the Lemmy side of ActivityPub is that it relies on a hub and spoke model. In practice this has failed when the hub goes offline, all the spokes are now left with independent copies of it's last known state and destroys the community progress (have to rebuild elsewhere, lose old content and references, etc.) if even you can regrow the community.
Mastodon has the similar problem but worse with content discovery; a user is not "seen" remotely by anyone until one remote person finds them and subscribes to their content explicitly. On every single remote instance, which of course is undesirable but that's how ActivityPub is designed.
I don't believe in ForgeFed terms this matters as much as being able to search across the federated network for repos, etc. which I think is a key feature. Sure issues and user accounts and whatnot, but an AP-linked FF-wide search would be insane on how useful it could be for users (and how to implement a "distributed search index" seems like a tough nut to crack).
A search is pretty "easy" (doing it distributed is just more expensive in terms of resources than a single index, because you end up doing multiple searches in parallel and merging results) - the main issue with search on the Mastodon side of things have been politics. That is, a lot of people like that discovery isn't as easy as searching. For subsets of the Fediverse where people actually agree search is a good thing or if the software specifically indicates consent or not, it'd be fairly straightforward to provide.
For Lemmy the hub and spoke model is essentially intentional - groups "belong" to a specific instance. But there's nothing in ActivityPub that'd prevent a USENET style model of groups either. There's nothing in ActivityPub that prevetns an application where a collection is effectively open to writing by all, and that would then relay messages to a sufficient set of "downstream" instances.
It'd be interesting to have that as an alternative to the Lemmy approach - I think the two could live quite well side by side.
> because you end up doing multiple searches in parallel and merging results
This reminds me of the design model of SearX/SearXNG - instead of a distributed forge index, it would distribute the search endpoints of forge instances to facilitate the next steps you outline. It almost feels like a central coordinator or maybe a CDN-like network set of search proxies would be needed to do the actual combining and filtering of results. Maybe it could fit in the Codeberg operational umbrella in some future plan.
In practice Nostr does this step on the client side - one subscribes to relays, then when querying for new content it asks all relays, gets all the duplicate metadata and filters on the client. Huge network use and battery drain on your handheld device, Nostr bouncers have emerged for this exact same reason, a popular software is "Bostr", easy to find examples run by random volunteers but it requires money (disk/cpu/ram): https://bostr.azzamo.net/
There are quite a lot of approaches you can take to reduce the cost of this, e.g. sharding by search term, so the number of shards hit for any specific search term is a subset of the total set.
You can also certainly broadly cache the "top" of the hit lists for very common searches, so you don't need to fan out unless you're doing less common searches or going beyond the first "page" of results.
Is AP the "right protocol", well, we shall see. i happen to think that, not so different from, say, smtp or imap, while AP does have some issues, i think AP will be *good enough*. I say, good enough, in order to get started, to get momentum...once that happens, then yes, things can be optimized...and by then the value of federation for things like code forges will be obvious, and then the next phases will be more about optimization - both technical and otherwise.
no AP is not the right protocol for shared/collaborative systems, the creators of forgefed have the same thoughts: https://forgefed.org/blog/actor-programming/.
It doesn't feel to me as if the author of that really get AP.
AP fundamentally rests on exchanging activities, that model operations on objects in collections.
Everything under their "basic concepts" section can map cleanly to an application that speaks AP.
AP has actors. Methods maps to Activities. Making networking transparent is down to wrapping things in a local framework that chooses when to use networking. Their concept of "vats" similarly is down to a lcal framework that calls method if local and posts AP activities otherwise.
AP provides a format for storing both the activities and other objects to disk, but you can choose to use your own, and that includes state that might reference other actors.
I'm working on an app server, in fact (not open source) that is based around those concepts and provides all of the things they're describing, but currently with AP as the main external protocol (that is likely to change - e.g. we're likely to use NATS for communication internally in clusters of these app servers).
Is there any server actually using this so one can see it in action? They only seem to list Vervis, but the linked https://vervis.peers.community/ is down.
Last obvious activity on the spec/issue tracker is a month ago (fairly recent), blog six months ago, forum a year ago. Sounds alive, but not particularly active.
See my other comment at https://news.ycombinator.com/item?id=44896910 .. community involvement determines progress. Especially since the goal is to mature open standard specification for the ActivityPub protocol extension there is a chicken/egg. The spec has most chance to become successful if there are early adopters who embrace the vision of forge federation.
[dead]
[dead]
im gonna bet this was gpt-5 as patio11 mentioned 1 line suggestion
> It’s a little rich, pardon the pun, to cash a check for $20 billion and then whine about fintechs freeriding on your IT spend.
I think you posted on the wrong thread.
yes, weird, lol