Hacker News Reader

I’m still fairly new to the team, and don’t claim to represent their point of view here, but my impression is that services (like moderation services) aren’t intended to be divorced from the communities they’re serving. It’s more that they’re decoupled from the physical data placement. The relationship between users and moderation services would be many-to-many. The incentives to self-organize and to provide a valuable service for your community are still there; it’s just that the notion of belonging to a community is more fluid in itself.

Fluid community would disincentive tight-knit community wouldn't it?

I feel that if you decouple the social reward and the grunt work of moderation and financial burden of hosting the relay, then the incentives just wouldn't be there to do the dirty work unless it becomes paid or monetized in some way.

> For all the faults of ActivityPub, the extremely “gated community” like approach provides the social incentive for users to feel a sense of belonging to a server, and for the server owner and moderator to feel a sense of pride and ownership over providing service to their users. Being within a valued community also incentivizes people to donate to pay for server cost and moderation effort.

are social incentives going to be enough long-term though?

I keep looking at this and thinking of three things: trust, security, and Reddit. These are actual questions, not arguments, I'm genuinely curious.

Can you trust an admin to host and police your social network? Moving servers isn't hugely difficult iirc, but it could be very disruptive and drama-ful. It would have to get pretty bad before people start to overcome the network effect inertia and actually move.

What is there to hold hosts accountable for security? The threat of reputational damage doesn't seem like it is going to mean much to pseudonymous volunteers, so what can be done to ensure hosts are properly protecting the system from promise?

Reddit moderators are, by and large, reasonable but there's a non-trivial minority who will do things like stage a coup against the other moderators, start arbitrarily banning or harassing people, or just straight up ghost the site and never follow up on the rules. same as above, what mechanisms exist to prevent or reverse or take over the actions of an rogue/absentee mod?

> are social incentives going to be enough long-term though?

I'd say all the long-running forum based communities proves that yes it is. Not counting Usenet, IRC and other "old internet communities" which have withstood the test of time.

> Can you trust an admin to host and police your social network?

That's where the federated part comes in, you choose a server and admin that you trust.

Preventing people from moving server would be holding them hostage, breaking the fundamental trust of the platform and become public enemy numero uno overnight.

I really doubt anyone would do it, but yes the chance isn't zero. Plenty of people host servers with their real identity and reputation on the line though.

If you are still paranoid you can join a commercial server where by contractual obligation they have to provide service to you and allow you to move away.

> What is there to hold hosts accountable for security? The threat of reputational damage doesn't seem like it is going to mean much to pseudonymous volunteers, so what can be done to ensure hosts are properly protecting the system from promise?

Again, you choose your server based on your risk tolerance. You can go with the main mastodon.social server, or join a server owned by a real person you feel is reputable/trustworthy, or join a paid server.

And I would disagree about pseudonymous volunteers not caring about reputation damage, the vast majority of people would feel a sense of ownership over their online identity, especially if it has a lot of clout.

> Reddit moderators are, by and large, reasonable but there's a non-trivial minority who will do things like stage a coup against the other moderators, start arbitrarily banning or harassing people, or just straight up ghost the site and never follow up on the rules. same as above, what mechanisms exist to prevent or reverse or take over the actions of an rogue/absentee mod?

Reddit mods are not server owners, at the end of the day they know they're just hosting someone else's party so there isn't a true sense of ownership.

But if a moderator decided to go rogue? It's just like a forum isn't it? Either the owner gets rid of them or you're out of luck.

You can limit damage by backing up your followers and follows on a regular basis so you can rebuild your network if you are forced to create a new account on a different server.

With federated system come the freedom to chose your server and the consequences thereof, you're gonna have to take some personal responsibility by choosing a server that has a healthy community and a responsible moderation team.

At the end of the day I don't think a perfect system exists, they are just different sets of compromises.

> For all the faults of ActivityPub, the extremely “gated community” like approach provides the social incentive for users to feel a sense of belonging to a server, and for the server owner and moderator to feel a sense of pride and ownership over providing service to their users.

I really misunderstood what you were talking about until you got here.

This mindset is extremely alien to me, so that's probably why it's so hard to make sense of this.

I am glad that you have a system that works for you, and that I have one that works for me.

I'm actually a fan of POSSE (https://indieweb.org/POSSE) where all social networks are auxiliary to my own website/blog.

After the Twitter debacle I'm done with the idea of being "married" to any network.

Since Bluesky published their protocol, I’m thinking about how one integrate a BS-compatible microblog into one’s own weblog software, e.g. POSSE.

With ActivityPub I can see that: a form of headless ActivityPub server which provides an Inbox and Outbox, based on the DB. Such you can publish your own posts both on the web and into an outbox. And even better, you get reactions in your inbox, which you could possibly display on your own web pages with enough determination, similar how the Indieweb people do that with WebMentions. After all every Status in Mastodon/Fediverse has an url property.

With AT Protocol I’m a little bit at a loss. You could possibly expose your Backend as a AT-compatible Personal Data Repository, although that would be a lot of work, exposing a Git-like interface.

But I’m still wondering how one would aggregate reactions. It seems it would not be enough just to have a PDS, but also to run an Indexer/Relay, which indexes other peoples PDS. And not just the PDSs of the people you are following, but also the rest of the world – after all a Like or such can come from everyone. When running an Indexer you are pretty soon into Firehose territory. Too much for a single person website.

It really seems there isn’t a way for reactions to swim upstream – the social graph of Bluesky in a way lives in the Indexer/App View world, not on your PDS.

Maybe I’m wrong, but the AT Protocol docs are not very expansive on such points. Neither is Klabnik’s blog. Everyone talking about ATP seems to be excited about the Solid-inspired DIDs and PDS, but never talk about the transmission mechanisms. Whereas I’m sitting here and thinking that an ActivityPub Actor’s Outbox is already a form of PDS – and it has an Inbox. Addressable via the Web and findable via Webfinger.

Reactions would be a Lexicon. They’d then get consumed like anything else.

Or at least, that’s my initial guess, would have to actually work through the design to know if it would work that way.

You’re talking about the data model, I’m asking about the transmission of those and its directions.

“Lexicons” are BS’s Not Invented Here variant of ActivityPub JSON-(LD) meta-syntax and the vocabularies. Obviously necessary for the transmission of information, but it doesn't tells you how that information is transmitted or in which direction.

Sorry, I meant mostly like, "the transmission doesn't work any differently than anything else," you don't need to invent a novel transmission model to make something work.

> But I’m still wondering how one would aggregate reactions. It seems it would not be enough just to have a PDS, but also to run an Indexer/Relay, which indexes other peoples PDS. And not just the PDSs of the people you are following, but also the rest of the world – after all a Like or such can come from everyone. When running an Indexer you are pretty soon into Firehose territory. Too much for a single person website.

You don't need to run a Relay yourself in order to see reactions; you instead subscribe to an existing Relay's firehose (such as the one that BlueSky PBC operates), and ignore anything that isn't "reaction-shaped" (matches the relevant Lexicon).

> Everyone talking about ATP seems to [..] never talk about the transmission mechanisms. Whereas I’m sitting here and thinking that an ActivityPub Actor’s Outbox is already a form of PDS – and it has an Inbox. Addressable via the Web and findable via Webfinger.

Here's my attempt to summarise the transmission difference between ActivityPub and AT Protocol: ActivityPub is symmetric and push-based, AT Protocol is asymmetric and pull-based.

With ActivityPub, your client talks to your server. The server handles both outgoing data (you making posts) and incoming data (viewing other people's posts).

When you create a post:

- The post is placed in your server's outbox.

- Your server looks up the servers for every one of your followers, and places your post in their inbox.

When someone creates a reaction:

- The reaction is placed in their server's outbox.

- Their server looks up your server, and places the reaction in its Inbox.

- Your website checks the Inbox, discovers the reaction, and handles it.

With AT Protocol, your client talks to your PDS and the client's App View. Your PDS handles outgoing data (you making posts), and your client's App View handles incoming data (viewing other people's posts). Relays are what provide transmission between the two: Relays subscribe to your PDS, and App Views subscribe to the firehose of at least on Relay.

When you create a post:

- The post is added to your repository on your PDS.

- The Relay pulls the post from your PDS and broadcasts it on its firehose.

- App Views see the post in the firehose, and include it within the feeds of users that follow you.

When someone creates a reaction:

- The reaction is added to their repository on their PDS.

- The Relay pulls the reaction from their PDS and broadcasts it on its firehose.

- Your website's App View (which might be your client's App View if "reactions" are also posts, or some other App View if this is a different kind of semantic data) sees the reaction in the firehose, and handles it (e.g. includes it within the feed of reactions that your website uses).

That is rather helpful, thanks!

But in a way depressing: I fear subscribing to a firehose is not that realistic for small single person websites. Maybe you can filter the firehose subscription.