It kind of makes me think of how odd it would have been if many of the old forums named themselves like bookclub.phpbulletin.com, metalheads.vbulletin.net, or something.

There's nothing wrong with doing that, obviously, but it's struck me as another interesting quirk of fediverse instances/sites. Generally as soon as you visit them you can tell by the site interface or an icon somewhere what software they're using.

you are viewing a single comment's thread
view the rest of the comments

[–] PeriodicallyPedantic@lemmy.ca 1 points 11 months ago (1 children)

Idk what to tell you then. Not only is that not how activitypub works, not all fediverse networks even use activitypub. Idk where you're getting your definition of fediverse, or how you think that's even possible. You can't have every app/network support every feature of every other.

Imagine I make a fediverse MMO turn based RPG. How is a Lemmy app support to present that? How am I supposed to consume that from a mastadon server? Mastadon shouldn't need to support turn based MMORPGs, and MMORPGs shouldn't need to support streaming video.

There is not only is there no common API for fediverse networks, there isn't even a common protocol.

[–] rglullis 1 points 11 months ago (1 children)

How is a Lemmy app support to present that? How am I supposed to consume that from a mastadon server?

You don't.

There is no place that says that a client needs to process every message that is received on an actor inbox. It doesn't mean that one client should support only one specific type of activity, or even servers for that matter.

[–] PeriodicallyPedantic@lemmy.ca 1 points 11 months ago (1 children)

Maybe I don't understand your position then.

Fediverse doesn't make any claims for SSO or shared user accounts between server types. And servers aren't required to interoperate with servers of other types. And clients aren't required to interoperate with multiple server types.

It's nice when servers and client do Interop between types (what I'm calling networks for lack of better word), but that's not really fundamental to the fediverse, and is pretty rare. Afaict the only requirement is that servers of the same type can interoperate with eachother and user accounts from other servers of the same type are addressable.

[–] rglullis 1 points 11 months ago (1 children)

server types

That is the problem. Assuming that we need different "server types" is a mistake made by Mastodon that benefitted them in the short term but screwed the developers who were looking at activitypub as a simple protocol for bidirectional exchange of data.

What we need is smarter clients and let the servers be completely dumb relays. Instead of thinking of "Mastodon API" or "Pixelfed API" or "Lemmy API", we could be looking at a single browser extension that could talk Activity Stream directly with the server, let the client be responsible for signing messages and know how to present the context when/how to serve the different activity types.

[–] PeriodicallyPedantic@lemmy.ca 1 points 11 months ago (1 children)

Isn't this just the difference between an API and a protocol?

The payload of a message for one social network will be different based on the capabilities of that type. There are API architectures that are discoverable, like HATEOAS, but that only gets you so far (and that example is based on HTTP not Activitypub).

I don't really see anything wrong, in the absence of a standard body, for each social network to define its own activity type, since they typically have some degree of unique capabilities anyways.

[–] rglullis 1 points 11 months ago (1 children)

Isn’t this just the difference between an API and a protocol?

Maybe? I don't know. Is that a relevant distinction on a decentralized system where the application logic can live on whatever side of the network?

There are API architectures that are discoverable, like HATEOAS, but that only gets you so far

Because they are constrained by the "client-server" paradigm. If you spend some time working with decentralized apps that assume that data is available to any nodes on the network, all your "protocol" really needs to do is to provide the primitives to query, pull and push the data around. I kinda got to write about it on an old blog post

[–] PeriodicallyPedantic@lemmy.ca 1 points 11 months ago (1 children)

I think it's still relevant. I mean... It's turtles all the way down, but applications on equivalent layers need to share a common API.

I don't think it's reasonable to ask voluntary instance hosts to pay for bandwidth and storage for networks they don't want to host, so mirroring the all Activitypub on all servers doesn't seem reasonable, especially if any of the networks take off on popularity. Imagine if every single fediverse instance of any type needed to be twitter-scale just because some instance of mastadon took off.

I think it's correct for servers of a specific network/type to only subscribe to messages of the type they care about, as a purely practical matter. It'd be nice if there was a fediverse standard used to announce capabilities, along with standards for common capabilities and restrictions, but there is none that I'm aware of.

[–] rglullis 1 points 11 months ago (1 children)

storage for networks they don’t want to host, so mirroring the all Activitypub on all servers

In my dream world, servers are only relays. They don't store anything, unless it wants to keeps a copy for one of its clients, like POP3.

[–] PeriodicallyPedantic@lemmy.ca 1 points 11 months ago (1 children)

In my dream world, servers are only relays. They don’t store anything That sounds a lot like an ISP, except an ISP can relay anything, not just activitypub, which makes it even better. unless it wants to keeps a copy for one of its clients ISP plus a CDN :p

for the same reason that ISPs don't solve the need for servers and serverside storage, moving all your storage to the edge is usually a bad idea. You're basically describing a serverless P2P social network, but with it comes all of the pitfalls of strictly-p2p apps. mainly, searching becomes prohibitively expensive, and if your client goes offline (eg you need to go on an airplane or your phone runs out of batteries) reliably catching up can be problematic. How would this work for PeerTube, for example. would ever client that cared about peertub need to keep a copy of every peertube video on every peertube server, just in case you wanted to search it? My phone would fill up instantly. Would my phone just save an address to look up the video from the original author's personal device? not only does that sound like a security nightmare, but also RIP to the author's data usage caps if they published from their mobile device.

I think that servers are needed. IDK if we need servers to partially mirror eachother like mastadon does, but i think that hosting the content on the servers themselves is the right practical move. and given that we're more or less boxed into a federated server-client architecture, then I think that we're getting it as good as we're going to get, until we choose some standards body to govern how to expose capabilities.

I do think that the right approach is to have a discoverable API where clients can discover what capabilities a certain piece of content has, and what those capabilities mean. Just like how javascript feature detection is far better than user agent detection, servers can integrate with any social network that supports some minimum set of capabilities, and clients can present all capabilities to the user (while ignoring unsupported capabilities) regardless of originating social network. but we're not there yet, we need that standard first, and major players need to agree on it.

[–] rglullis 1 points 11 months ago (1 children)

That sounds a lot like an ISP,

No, that sounds exactly like Nostr, which is a lot more practical and cheap to run that a Mastodon server and actually scales quite well.

moving all your storage to the edge is usually a bad idea.

No. You just need to move the application state to the edge. Storage itself can still be in content-addressable data servers, like IPFS, magnet links or plain-old (S)FTP servers.

When someone posts a picture on Mastodon, the picture itself is not replicated, just a link to it. Now, imagine that your "smart client" version of Mastodon (or Peertube, or Lemmy) wants to post a picture. How would it work?

User posts the photo to an IPFS server. It could be a cloud server or it could be their own NAS they have it running at home.
The uploaded photo generates a hash.
Client takes the hash of the photo and puts in the message.
Client signs a message and send to the server
Server receives the message, processes it (index metadata, puts the image in its cache to help with seeding, etc)
The server has a policy of keeping the image in the cache in the outbox until it has been delivered to at least 70% of the other clients or 5 days, whichever happens first.

I think that servers are needed.

If by "servers" you mean "nodes in the network that are more stable and have stronger uptime/performance guarantees", I agree 100%. If by "servers" you mean "centralized nodes responsible for application logic" then I'd say you can be easily be proven wrong by actual examples of distributed apps.

[–] PeriodicallyPedantic@lemmy.ca 1 points 11 months ago

Looking at nostr, I generally like the architecture, although the it's very similar in broad strokes.

I like the simplification and separation of the responsibilities. I don't like using self signing as an identification mechanism for a social network.

But crucially it seems like it has the same problem we're discussing here, wrt different social networks based on that protocol, having different message schemas and capabilities, making them incompatible.