Head twist: How do #ActivityPub server implementations like Mastodon not understand that account transfer means the whole digital content related to an account, not just selected pieces.
Analogy: This is operating like old school bank accounts where followers are direct debits and who you follow are standing orders. Your content (transactions) don’t move to your new bank but you have statements (export of data).
It’s digital and data plus 2023. We can do so much better. Wander pondering.
@dahukanna the implementation detail starts to leak out really badly here. The underlying content isn't rewriteable, it's a stream. So the only way to migrate old content would be to send *all* of that data to every server, modified, and backdated, without having it show up in any feed because it's not "new" content.
Which is fine, actually. Some implementations might have issues with it, but I don't see any actual barriers, and I suspect mastodon would behave pretty normal with that, even
Interesting. So ActivityPub protocol is stateless content transportation like HTTP, FTP, TCP/IP, UDP/IP?
Why not have post URLs and alias model? Social media is about personal expression and conversation, not ledger book transactions.
Now I understand how the fragmented and missing conversation effect happens. That’s instream, without changing servers.
@dahukanna
> Now I understand how the fragmented and missing conversation effect happens
It can be a result of moderation actions too; mutes/ blocks by users/ servers, followers-only posts etc. But as you say, there does seem to be a network-level issue too.
Some of what you're saying is a bit behind my technical understanding, and it's late here. But good stuff to share at the AP dev watering holes, eg:
http://socialhub.activitypub.rocks/
#fediverse-city:matrix.org
@dahukanna @hazelweakly It literally is JSON over HTTP and the identifier is the URL, intrinsically tied to a hostname. So the meaning of moving posts to a new server is not obvious, and that's why Mastodon hasn't attempted it.
CalcKey copies history apparently. I don't know what decisions they have made around it.
If I migrate from hostsrc to hostdst and my post hostsrc/B refers to post hostsrc/A, should hostdst/B get rewritten to refer to hostdst/A?
If hostsrc is also a CalcKey, does it set up redirects so that any edits to hostdst/C can be seen by people who go to hostsrc/C? If hostdst sends out edits to hostdst/C, will any receiving servers know to apply the edits to their local copy of hostsrc/C?
I was suggesting that the post should have it’s own atomic identifier and then qualified by the host name doing the publishing/syndication to allow for checking for content/moderation compliance.
That’s simply how the underlying ActivityPub system was designed. It was intentionally designed around instances, not users.
In ActivityPub the system is centralized around instances. They are the core unit.
So things like account transfers are sort of irrelevant to the core protocol. Why, the protocol would ask, would anyone want to do that?
We could do better. But the designers of the system decided to go a different direction.
This is one of the reasons some people are optimistic about Bluesky making better choices.
“So things like account transfers are sort of irrelevant to the core protocol. Why, the protocol asks, w(sh)ould anyone want to do that?”
This assumption is giving me prototype-inheritance deja-vu. This is ask-assuming, “why should people move ISPs or web servers”?
An ActivityPub *streaming* server instance can be defederated or stop operating & shutdown. Instances are ephemeral, people are not.
Servers provide compute runtime, access, distribution & moderation of users content.
SparkIT
Dawn Ahukanna
Hazel Weakly
Strypey
clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛
Laurens Hof
Jon
volkris