5 ms·

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

I'm actually a fan of POSSE (https://indieweb.org/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.

ttepasse 3y ago
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.
- steveklabnik 3y ago
  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.
  - ttepasse 3y ago
    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.
    - steveklabnik 3y ago
      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.
- str4d 3y ago
  > 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).
  - 3y ago

ttepasse 3y ago

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.

steveklabnik 3y ago
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.
- ttepasse 3y ago
  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.
  - steveklabnik 3y ago
    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.
str4d 3y ago
> 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).
- 3y ago