The TikTok ban and Donald Trump's rise to power show how fragile our social media accounts are. We must normalize and invest in decentralized social media.
Instance A goes down, you can’t post as your user registered on instance A.
With cryptographic identities it’s possible that instance A should be up only when you are registering your user. It’s even possible with some delegated rights to another A user that only that user should be up when you are registering your user, the instance itself - not required.
I’m against the whole idea of federation like in XMPP or like in ActivityPub. It’s stone age. It requires people to set up servers. It ties users to those servers. And communities are unnecessarily ties to servers. And their moderators.
Ideologically Retroshare looks nicer, for example.
You need to have messages, containing all the data I’ve described (who messages whom or who messages which communities and time of a message should be used to reduce the amount of data, ahem, stored and transferred by nodes, and also messages should list their dependencies, like - if you are giving some user some mod rights and taking them away a few times in a row, you need to know what the previous message was and the one before it), and shared storage. Shared storage here kinda breaks the beauty, because storage is finite and in fact probably those machines contributing it would function a lot like instances, replicating only communities they want.
Above that messages layer there’d be the imagined social network itself. I suppose it comes down to CRUD signed by user, user signed by an instance root or better a user delegated that right by an instance root. So everyone can send CRUD messages on anything, but what of all this the client considers depends on what they trust and the logic of processing rights. DoS protection and space conservation here are a case of dependency management, kinda similar to garbage collection.
Then entity types - I guess it’s instance (people like that crap), community (I think this can be many-to-many with instances, instances are used for moderating users, communities for moderating posts), user (probably a derived user, from what I’ve heard but not understood about blind keys), public post (rich text with hyperlinks to entities by hash, everything is addressable by hash), blob (obvious), personal message (like public post, but probably encrypted and all that).
Federation allows this, no? Provided your instance is old enough to have federated with the content in the first place.
Instance A goes down, you can’t post as your user registered on instance A.
With cryptographic identities it’s possible that instance A should be up only when you are registering your user. It’s even possible with some delegated rights to another A user that only that user should be up when you are registering your user, the instance itself - not required.
I’m against the whole idea of federation like in XMPP or like in ActivityPub. It’s stone age. It requires people to set up servers. It ties users to those servers. And communities are unnecessarily ties to servers. And their moderators.
Ideologically Retroshare looks nicer, for example.
You need to have messages, containing all the data I’ve described (who messages whom or who messages which communities and time of a message should be used to reduce the amount of data, ahem, stored and transferred by nodes, and also messages should list their dependencies, like - if you are giving some user some mod rights and taking them away a few times in a row, you need to know what the previous message was and the one before it), and shared storage. Shared storage here kinda breaks the beauty, because storage is finite and in fact probably those machines contributing it would function a lot like instances, replicating only communities they want.
Above that messages layer there’d be the imagined social network itself. I suppose it comes down to CRUD signed by user, user signed by an instance root or better a user delegated that right by an instance root. So everyone can send CRUD messages on anything, but what of all this the client considers depends on what they trust and the logic of processing rights. DoS protection and space conservation here are a case of dependency management, kinda similar to garbage collection.
Then entity types - I guess it’s instance (people like that crap), community (I think this can be many-to-many with instances, instances are used for moderating users, communities for moderating posts), user (probably a derived user, from what I’ve heard but not understood about blind keys), public post (rich text with hyperlinks to entities by hash, everything is addressable by hash), blob (obvious), personal message (like public post, but probably encrypted and all that).
OK, dreams again