@maegul@hachyderm.io @torb@octodon.social #BlueSky is a fascinating experiment to watch, and if there’s one thing we’ve learned from all the work on decentralized/federated social web systems over the past 13+ years (certainly since the first Federated Social Web Summit^1), there’s LOTS of room for and benefits to many folks working on solving many hard problems in parallel, even if with totally different approaches, which can learn from each other. We learned this lesson in the #W3C Social Web Working Group^2. Also a key reason the #IndieWeb community adopted a core principle of Plurality^3. I have a lot of sympathy for "so many non-techies bounce off Mastodon because it’s just too technically difficult for them", it’s one of the reasons I send most folks directly to https://micro.blog/ — it supports following / #federating with #Mastodon, and it supports core IndieWeb W3C standards like Webmention and Micropub. Regarding what portability requires, I for one disagree that account or post portability needs "signed data repositories and DIDs". I believe that cooperative server-to-server portability can be achieved without it, and frankly, if you‘re wanting to design for uncooperative servers, what expectation can you have that they’ll support any standards or interop whatsoever? Beyond Mastodon-to-Mastodon account migration, we already have Mastodon-to-BridgyFed (IndieWeb) and Mastodon - to - Micro.blog, and I expect we’ll see that grow to include all directions of all combinations thereof. I am also optimistic that the “fediverse” will continue evolving various solutions that put users first in different ways, because there are users with different needs. There’s certainly a current #fediverse hierarchy that puts a lot of power (and burden of responsibility) in the hands of ”server/instance” admins — “feudalverse” was a running joke for a while, reflecting a #federation of instance admin feudal lords and their user serfs. Ironically, the more that account+posts migration/portability is supported, the more incentive there will be for harmonious and respectful relationships between instance admins and users, so I only see this situation improving in the future. Long reply summarized: I think the folks innovating at BlueSky are charting interesting waters, the Mastodon development community continues show through improvements that they prioritize users and their identity & data ownership, and the IndieWeb community continues to support & play with those and many other solutions, building bridges^4 between^5 them^6 to interconnect all the things. Glossary BridgyFed https://fed.brid.gy/ Micropub https://indieweb.org/Micropub Webmention https://indieweb.org/Webmention References ^1 https://indieweb.org/Federated_Social_Web_Summit#Portland_2010 ^2 https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web ^3 https://indieweb.org/plurality ^4 https://brid.gy/ ^5 https://fed.brid.gy/ ^6 https://github.com/snarfed/bridgy-fed/issues/381

@maegul@hachyderm.io @torb@octodon.social #BlueSky is a fascinating experiment to watch, and if there’s one thing we’ve learned from all the work on decentralized/federated social web systems over the past 13+ years (certainly since the first Federated Social Web Summit¹), there’s LOTS of room for and benefits to many folks working on solving many hard problems in parallel, even if with totally different approaches, which can learn from each other.

We learned this lesson in the #W3C Social Web Working Group².

Also a key reason the #IndieWeb community adopted a core principle of Plurality³.

I have a lot of sympathy for "so many non-techies bounce off Mastodon because it’s just too technically difficult for them", it’s one of the reasons I send most folks directly to https://micro.blog/ — it supports following / #federating with #Mastodon, and it supports core IndieWeb W3C standards like Webmention and Micropub.

Regarding what portability requires, I for one disagree that account or post portability needs "signed data repositories and DIDs". I believe that cooperative server-to-server portability can be achieved without it, and frankly, if you‘re wanting to design for uncooperative servers, what expectation can you have that they’ll support any standards or interop whatsoever?

Beyond Mastodon-to-Mastodon account migration, we already have Mastodon-to-BridgyFed (IndieWeb) and Mastodon - to - Micro.blog, and I expect we’ll see that grow to include all directions of all combinations thereof.

I am also optimistic that the “fediverse” will continue evolving various solutions that put users first in different ways, because there are users with different needs.

There’s certainly a current #fediverse hierarchy that puts a lot of power (and burden of responsibility) in the hands of ”server/instance” admins — “feudalverse” was a running joke for a while, reflecting a #federation of instance admin feudal lords and their user serfs.

Ironically, the more that account+posts migration/portability is supported, the more incentive there will be for harmonious and respectful relationships between instance admins and users, so I only see this situation improving in the future.

Long reply summarized: I think the folks innovating at BlueSky are charting interesting waters, the Mastodon development community continues show through improvements that they prioritize users and their identity & data ownership, and the IndieWeb community continues to support & play with those and many other solutions, building bridges⁴ between⁵ them⁶ to interconnect all the things.

Glossary

BridgyFed
https://fed.brid.gy/
Micropub
https://indieweb.org/Micropub
Webmention
https://indieweb.org/Webmention

References

¹ https://indieweb.org/Federated_Social_Web_Summit#Portland_2010
² https://tantek.com/2023/051/t1/five-years-ago-w3c-social-web
³ https://indieweb.org/plurality
⁴ https://brid.gy/
⁵ https://fed.brid.gy/
⁶ https://github.com/snarfed/bridgy-fed/issues/381