I get what you’re trying to say but I think the analogy kinda falls apart when you consider that email is a vastly simpler system with more constraints, which makes clients easy to separate from servers. It was designed to be easily separable.
The difficulty with social protocols is that social interaction is insanely varied and not clearly defined (and it probably shouldn’t be). There’s a million more kinds of social features you would want to build with a social protocol or social app that an email client could never consider. Some of these features are simply infeasible to build client-side only. E.g. algorithmic recommendations or content sorting that depends on a global view of all data (you definitely don’t want to do that in a client).
Maybe you could try to make those kinds of features part of the general protocol. But there’s all kinds of features you could think about and they don’t all work the same way. I have a hard time seeing how you could standardise them without restricting what is possible to build.
The “social protocol” of ActivityPub is also simple: you send activities to your followers (or other recipients). All the complexity in the fediverse is happening at what would have otherwise been the AP client layer. Things like algorithmic recommendations or content sorting ought to be done by dedicated applications with their own application logic. The bit that they outsource to the ActivityPub server is the part where you want to notify your followers that you did a thing.
Of course, if the complexity is between clients, then it should be easier to see why we need client-to-client protocols and support for negotiating capabilities and/or sessions between any two clients. Something like E2EE is going to require addressable clients, or else your “end” gets terminated at your server, where your server operator can read it. Something like the chess client probably needs a similar client capability or session negotiation with other compatible chess clients.
There’s an argument to be made that perhaps this shouldn’t be done via ActivityPub, and that ActivityPub should be a simple notification mechanism, but we’re well past the point where anyone cares for that sort of argument. We seem to be building a virtualized network+transport+session+presentation+application layer within the existing application layer.
If this is true, I kinda wonder why AP is not built on top of email rather than HTTP with JSON. If it is as simple as sending stuff to followers, couldn’t we just have extended email somehow?
I posit that it is not that simple in reality (and it shouldn’t be).
I don’t understand - what application? If you mean the server, then isn’t that what’s already happening? I mean servers have these features in their own application logic and make it available to clients via their APIs. So isn’t that working as it should? Or do you mean that the “base” of the interaction should be using C2C i.e. “just activities sent to followers” and then these extra features like algorithmic recommendations should be something on top that isn’t using a standardised API?
The data in email lacks structure beyond just “content”, sure you can stuff lots into headers, but ultimately email is text centric — there’s no relationships or discrete actions beyond something analogous to Create(Note)
In that it doesn’t follow the s2s AP spec, and doesn’t even implement the c2s spec. To be clear, I wasn’t making a value judgement on whether Mastodon is a good example of federation. But I have seen plenty of opinions from other implementers about its failings, going to right back to the way it added Direct posts that showed up on other OStatus implementations as Public posts (the only kind OStatus can handle), so …
Sorry I didn’t make this clear. The key point is in the sentences before the one you quoted;
Matrix works in practice as AP was intended to work (at least as Christine saw it). I can use the web app at chat.iridescent.nz to login to the homeserver at the same domain; matrix.iridescent.nz. But I can also use it to login to any other homeserver I like. Similarly, I can use the default web app at another Matrix homeserver to login to matrix.iridescent.nz.
Here’s how that could look in the fediverse. Imagine Bob is mainly a video guy. He hosts a channel on a PeerTube server, video.foo.social, where he posts his videos. But when he starts getting a lot of comments on his videos, he realises the PeerTube web app isn’t the best tool for conversations.
So when he wants to handle comments, he uses the Mastodon web app at notes.foo.social to login to to his account at video.foo. Now he can see each of his PeerTube videos in its Mastodon incarnation (as a Note with a link), and the string of comments hanging off each one. He can favourite, reply to or boost comments, as appropriate.
Conversely, Alice is a writer, who enjoys the challenge of a character limit. So she has an account as notes.foo.social. But when she wants to browse fediverse videos, or occasionally post a video, she can use the PeerTube web app at video.foo.social to login to her account at notes.foo.social. Also, when she finds herself wanting to post a long form text, she can use the FireFish app at stories.foo.social to login to that same account.
Am I making more sense now?
That’s a good reason to build more stuff on top of the base spec, not a good reason to ignore it altogether. It’s also not a good reason to constrain the default Mastodon web app to only being able to login to one server.
This is my understanding of what ActivityPods is working on.
This is something that I’d love to change, but it’s complicated. Involves both OAuth and session changes, but there’s no technical reason you shouldn’t be able to be logged into multiple accounts on a single server simultaneously, nor being able to use the Mastodon Web UI with accounts across different servers (note: this excludes accessing the settings)
you pass activities around your social graph and then it’s up to clients to interpret them. something like an algorithmic recommender would ingest activities from your inbox or outbox and then also the inbox/outbox of anyone else who connects to it and gives it access or otherwise sends activities to it. if it provides another API on top of that, then ideally that API would also be standardized.
i mean, in theory you could send a multipart mail where one of the parts is as2 and then if the inbox you’re sending to has an “activitypub handler” connected to it, it could handle the side effects. but activitypub is often intended for websites and web services so they already speak HTTP, and introducing a dependency on running an entire SMTP server is a lil extra
No, not really. You seem to be conflating “monolithic server+web-app” with “inflexible default user interface”. I’m interpreting “monolithic” as being “tightly-coupled” and that the server is constrained to only use the server’s specific web app. Neither of those is true in the Mastodon case.
The mobile Mastodon client I use allows me to log into any number of Mastodon servers (different actors, of course, but that’s a different topic). There are browser-based UIs that support the same. I haven’t tried it, but if PixelFed or PeerTube implemented the Mastodon API accurately enough, I’d be able to log into those servers as well, as you describe. (However, I’d guess that they don’t have a Mastodon API implementation that’s good enough to support it.)
Strongly disagree. It’s an excellent reason for a UI developer to ignore it altogether. Even if a developer built on the current C2S spec, they’d need a server to support the extended features. AndStatus is the only attempt I know about that’s tried to implement a non-toy C2S-ish UI. I don’t know anybody that uses that UI and I’ve heard secondhand reports of issues with it even with servers that implement the server-side of C2S (not surprising, given the underspecification of the C2S API).
Have you ever tried to implement a UI with C2S (one with a decent UX)? How familiar are you with the spec? I have trouble understanding how anyone who with a good understanding of the C2S part of the AP Recommendation would think using it for a serious UI implementation is a good idea.
Maybe you meant that people who are interested in specification work (versus most UI developers) should extend the C2S spec to make it useable? If so, I agree with that. If that happens, and especially if it improves on Mastodon API features, developers might consider implementing it. However, it’s a big project.
Seems irrelevant to me. If you don’t like the Mastodon apps provided by the server, use one of the many other third-party Mastodon UIs that use the Mastodon API.
Mastodon implements the federation protocol and supports all activities described in the ActivityPub spec, that makes it an “ActivityPub conformant Federated Server”. Servers are not required to implement client-to-server protocol. You can read about that in Specification Profiles section.
I’ve also seen them, but most of the time these opinions are expressed by people who are not implementers, or those who don’t understand the specification.
It is true that Mastodon is not fully conformant (for example, it puts wrong media type in Accept header, and its activity IDs are not dereferencable), but it is not the biggest offender and not special in any way (from implementers’ perspective). As I said, every single implementation has bugs and quirks, and interop with less popular projects requires much more effort because there are so many of them, and because generally they have more bugs than Mastodon.
Well that’s all very good to know. Anyway, a while back we were talking about mapping out how to implement Mastodon compatibility using AP+FEPs. Is that still something people in this thread are still interested in @codenamedmitri@trwnh@SorteKanin@thisismissem?
So this would only work with posts from the people who chose to send their activities to the application? That doesn’t sound feasible, the point is to get recommendations or sort through the entire known set of posts. How would this application get all the posts?
I’m also a bit confused as to why a feature like algorithmic recommendation or a feed sorted in some clever manner should not be considered for inclusion in the protocol, but only relegated to some external dedicated application.
I imagine that if I am using a C2S client application, my “feed” would basically just be my inbox? Which presumably would be only chronological order. But what if I am following so much stuff that I can’t possibly keep up with the content posted in chronological order? Like if I get 100 new posts a second or something, for example.
If I wanted to view my “feed” with a different kind of sorting or with recommendations or something, how would I achieve that in a C2S client with a good UX? It feels like if it was in a separate application, it could not possibly be part of my normal feed in the C2S client. I’d need to somehow go to this separate application to get those features? I really don’t see how this could be done in a way that facilitates good UX.
Mastodon does not actually fully conform with this profile. The way that Mastodon uses these activities is not covered in ActivityPub. There are additional semantics and processing requirements added by Mastodon to power their “decentralized social network” application of ActivityPub.
Bugs according to what? Part of the problem is that there is not a documented protocol with a clear set of requirements layered on top of ActivityPub. If a project implements something according to the spec but in violation of what Mastodon requires, is that a “bug”?
Loosely, in the sense that I have approached it in the past, but I am not sure it is the best course of action to continue to pour more energy and resources into the Mastodon worldview. I’d rather push Mastodon in a better direction if possible, while filling in the gaps in the ActivityPub spec.
How is that any different than what is currently done? The “known set” is what the application receives or pulls. You can’t operate on information you don’t have.
No, your client can do whatever it wants with the activities in your inbox.
Application features live inside applications, yes. The application can use C2S to store or deliver activities. That’s just one single “feature” of the application. If you wanted to convert Lemmy (or any other current fedi software) to an AP C2S Client, the only thing you would need to do (besides assuming the existence of a compliant Server) is to add a login/authorization flow against a pluggable Server. Then Lemmy (or whatever software) would continue to run exactly as it runs currently, but the activity delivery would be handled by the AP Server instead of by some internal process. Lemmy (or whatever software) would still produce exactly the same activities as it currently produces, but instead of POSTing them directly to inboxes, it would POST them to outboxes. In exchange for this, you avoid every single implementation having to do its own delivery logic from scratch.
It’s really not a huge drastic change to say that hey, maybe we shouldn’t be doing the equivalent of expecting everyone to be constructing raw SMTP messages all the time. The fact that everyone does basically this is what leads to bugs all over the place and subtle incompatibilities, because this is hard stuff and I don’t think every single new implementation should have to write delivery and federation logic from scratch before it can focus on what really matters in its application functionality.
I think documenting all the things required for federation with Mastodon as a thing would be a good idea, if these pages don’t do enough already (PRs probably welcome):
The “known set” for a server is usually bigger than for a client - that is the difference. Algorithmic recommendations will for instance often include stuff you don’t follow, so your client would presumably not even have received the activity it would want to recommend.
I think I’m also confused as to whether this dedicated sorting/recommending application you are suggesting lives in the server or in the client (or as a separate client?) or in a third place (third party server I guess). Which is it?
Yes but the inbox itself is chronological - which means that if I were to make another sorting, I would need to download and keep in a local database every single activity from my chronological inbox, no? That doesn’t seem feasible.
Okay let’s take the example of Lemmy to be more concrete. I really don’t understand how Lemmy could be made as a client. Lemmy takes all known posts on the instance (including stuff you don’t personally follow, in the case of the “All” feed) and sorts them in a clever way that prioritizes recent posts with many upvotes.
To make this sorting, you need a global view of all known posts and all their up/down-votes. This is a lot of data (gigabyte scale) and sorting it is not a fast process. I do not see how it is feasible for a client application to perform this work (also just seems super wasteful for every single client to perform this work instead of the server doing it once).
Could you explain how Lemmy could be done as a client? Because I really don’t see how.
You tried to explain it before here but I didn’t get it and you didn’t explain further:
The server is the client, in this case. Being an AP Client doesn’t require running locally or even necessarily being a user-agent. It just requires you to interface with outboxes and inboxes from the “other side” – GET inbox POST outbox, instead of POST inbox.
Existing fedi implementations already do this.
It’s done in the exact same way that it’s already done.
