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...

▲

vidarh 6 days ago | parent | next [-]

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..

▲

styanax 6 days ago | parent [-]

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).

▲

vidarh 5 days ago | parent [-]

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.

▲

styanax 5 days ago | parent [-]

> 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/

	▲	vidarh 5 days ago \| parent [-]
		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.

▲

mxuribe 6 days ago | parent | prev | next [-]

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.

▲

nerdypepper 6 days ago | parent | prev [-]

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/.

	▲	vidarh 5 days ago \| parent [-]
		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).