Hacker News Reader

Comment by grishka | Hacker News Reader

The C2S part of ActivityPub is, to put it mildly, cumbersome. It also shifts way too much logic to the client and prevents an efficient database design.

There can, theoretically, be a "dumb" AP server that implements both S2S and C2S and expects the client to do all the heavy lifting. In practice, all current ActivityPub servers are "smart". They treat the S2S protocol as more of an API, and have their own web UI with a specific user experience (Mastodon, Pleroma, and Misskey are microblogs, PeerTube is a video platform, Lemmy is a link aggregator, Smithereen is a social network, and so on). Interactions between these different experiences generally work on a best-effort basis. You can't shove Reddit into Twitter UX and expect something nice to come out, no matter how hard you try.

View on HN

I'm not recommending that all server-side logic be inside of that single ActivityPub server.

What I would like is to run a "dumb" ActivityPub server that would hold all my activity and federate, by receiving and sending arbitrary JSONLD documents. This would be my only identity. Then, other servers like PeerTube, Gitea, etc can talk to that server for their federating needs.

When I stumble on a video post on Mastodon, I would have a link to open it in my PeerTube instance, where peer-to-peer video transmission would be implemented; but whether I retweet or reply from Mastodon or PeerTube, the same identity would be used. When I stumble on a merge request on Lemmy, I would have a link to open it in my Gitea instance, where Git repositories would be supported; but whether I upvote it from Lemmy or approve it from Gitea, the same identity would be used.

This would fit the narrative of the video.

> Imagine if you could share videos, events, instant messages, microblogs with the whole universe. Imagine if it didn't matter which planet you came from.

> Your login on any of those services allows you to interact with a whole diverse universe.

> You can't shove Reddit into Twitter UX and expect something nice to come out, no matter how hard you try.

Why not? it's text; you could make the same exact post on reddit and twitter (barring the length, which could be truncated in a federated context). Link aggregation is basically just microblogging with the extra constraint that the initial post has to have a link.

> Smithereen is a social network

What does this mean? Every other platform you mentioned are social networks. On all of these platforms, a user posts text or media posts. Displaying them in a different UI doesn't make them radically different.

> Why not? it's text;

The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.

> What does this mean? Every other platform you mentioned are social networks.

I meant a Facebook-style social network.

> The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.

That's subjective and exactly the type of thing that could be handled in a client. In both cases you're displaying the exact same data. A microblogging thread may be displayed as a flat list, but it's still a tree like a link aggregator thread.

> I meant a Facebook-style social network. So a platform to post what are essentially blog posts. In ActivityPub, that would be the Article type, which, according to the spec, has no semantic difference from Note. An Article could be created as a Note and vice versa with no semantic difference or loss of data. Just like above, the data is the same and the only distinction is the visual presentation of it.

> That's subjective and exactly the type of thing that could be handled in a client.

There needs to be a web UI of some sort. You need to be able to send people links to things that they can open in their browser with nothing extra installed. It's a hard requirement. You can't require the use of a client app.

Right, but that doesn't mean the server can't support other post types or leave complex UI to other clients. Each server could fallback to displaying a link to an external post at a bare minimum, or display whatever the `content` field. I'm just arguing that the C2S is perfectly viable and would make the fediverse so much richer and more usable. Using the Masto API to federate only specific types with specific software is limiting the fediverse.

Reply on news.ycombinator.com