First, a technical note. ActivityPub does not formally define the followers only post. It was just kind of invented later, and it shows. Alice wants to post something like “I’m having a sad day“, which is kinda personal and negative, so she makes it followers only. Bob sees it, and replies “Sorry about your tough day.” Bob’s software is really smart and noticed that Alice’s post was followers only, so therefore Bob’s reply is followers only as well, and thus Bob’s reply gets sent to… Bob’s followers. Who are not Alice’s followers. So now, while they can’t see Alice’s post, they can certainly make some inferences about what was posted based on the contents of Bob’s reply. I don’t know who decided this was the smart thing to do. I am inclined to say it’s not that smart.
Followers-only scope was introduced by Mastodon, and it’s 100% as bad as Ted says. It absolutely breaks the possibility of having any meaningful kind of threading, and as far as I can tell it is purely the result of what was easy to implement given the original Twitter-like design of the app itself.
I believe there are plans in Pleroma to do something better, but better infrastructure in Pleroma tends to have a hard time making into the front-end, so I guess we’ll see what we see, someday.
That sounds pretty broken. I wonder what the right approach actually is. In a decentralised system, what prevents a follower from sharing a message (or the key to decrypt a messy?).
The lesser known Zot protocol incorporates privacy as a design requirement from the start, which is why I prefer it over ActivityPub.
To my knowledge, how Zot solves this particular issue is enabled by their identity system, where all entities have key pairs allowing others to verify the authenticity and integrity of any post in the network.
From the message spec:
Followups to any post (replies, likes, reactions, etc.) MUST be sent as a private activity (single recipient) to the sender of the original with a message type ‘response’. This is referred to as an “upstream delivery”.
Additionally these activities MUST provide an ‘inReplyTo’ element set to the id of the activity that is the object of the response. Implementations SHOULD support multi-level likes. Servers MAY support multi-level comments.
The original sender MUST resend the followups to all of the original message recipients using message type ‘activity’. This is referred to as a “downstream delivery”.
This single-source mechanism ensures the original sender’s privacy settings are respected and conversations are kept intact for all recipients of the original message.
For those interested, I recommend taking a look at Zap and Hubzilla (Hubzilla also federates with ActivityPub, Friendica, Diaspora, and some other protocols to an extent). They’re really interesting, and I wish Zot would see more adoption in the fediverse.
Honk is the authors intentionally minimal implementation of activity pub. (An alternative to twitter.)
Honking is like tweeting. Big M is mastodon, the most popular implementation of activity pub.
I believe there are plans in Pleroma to do something better, but better infrastructure in Pleroma tends to have a hard time making into the front-end, so I guess we’ll see what we see, someday.
I think some main Pleroma dev (?) asked the fediverse just the other day what they’d think about leaving ActivityPub compability behind
Followers-only scope was introduced by Mastodon, and it’s 100% as bad as Ted says. It absolutely breaks the possibility of having any meaningful kind of threading, and as far as I can tell it is purely the result of what was easy to implement given the original Twitter-like design of the app itself.
I believe there are plans in Pleroma to do something better, but better infrastructure in Pleroma tends to have a hard time making into the front-end, so I guess we’ll see what we see, someday.
That sounds pretty broken. I wonder what the right approach actually is. In a decentralised system, what prevents a follower from sharing a message (or the key to decrypt a messy?).
The lesser known Zot protocol incorporates privacy as a design requirement from the start, which is why I prefer it over ActivityPub. To my knowledge, how Zot solves this particular issue is enabled by their identity system, where all entities have key pairs allowing others to verify the authenticity and integrity of any post in the network. From the message spec:
For those interested, I recommend taking a look at Zap and Hubzilla (Hubzilla also federates with ActivityPub, Friendica, Diaspora, and some other protocols to an extent). They’re really interesting, and I wish Zot would see more adoption in the fediverse.
A bit too much jargon for me to grasp what is going on here? Anyone care to break it down?
Honk is the authors intentionally minimal implementation of activity pub. (An alternative to twitter.) Honking is like tweeting. Big M is mastodon, the most popular implementation of activity pub.
Thanks 👍
I think some main Pleroma dev (?) asked the fediverse just the other day what they’d think about leaving ActivityPub compability behind
One thread I found immediately: https://pleroma.site/objects/ea5dcdfa-e4ab-47d1-94de-79ce7b0cf423