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.
[1] https://codeberg.org/forgejo-contrib/federation/src/branch/m...
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).
[2] https://www.w3.org/TR/activitypub/
> 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.
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...
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'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.
[0] https://communityblog.fedoraproject.org/fedora-chooses-forge...
> 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-...
Screenshot: https://postimg.cc/WFDzQndC
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.
Automatic replication so that 3 copies are always available through the network, even in 50 years.
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 "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..
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).
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.
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/
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.
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).
> 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.
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.
tomhow•5mo ago
ForgeFed - https://news.ycombinator.com/item?id=37362088 - Sept 2023 (63 comments)