Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Transparent account migration is one of the most interesting parts of AT to me, as a user, so I for one am glad they went their own way.

That said I don't really know Matrix at the protocol level, so I can't really speak to it, but just based off of what you said.



So Matrix also has account portability (almost) - https://github.com/matrix-org/matrix-spec-proposals/blob/keg... and https://github.com/devonh/matrix-spec-proposals/blob/cryptoI..., implemented in Dendrite. Unfortunately dev is paused on it currently thanks to lack of $ though.

The AP approach (prioritising portable identities over portable account data) is cute though, and perhaps we should have prioritised that as an alternative to fullblown cryptographic IDs & account portability.


Thanks for the context! I use Matrix daily, so I am interested in these details, I just haven't found the time to dig into things yet.


The ideal situation is that BlueSky and Matrix (/Element, let's be real) are giving hoards of money and are dancing around each other in a daring game of adversarial interop.

I want a Cold War-scale federation competition, dammit! :)


I would love both BlueSky & Matrix (and/or Element) to be given hoards of money and for us to race each other to the best federation imaginable (and then bridge it all together and live happily ever after)


To be clear, strong account portability predates Bluesky by ~5 years. Peergos[0], as reviewed by Jay before Bluesky Inc was created, has had this for years:

https://book.peergos.org/features/migration.html

So they didn't actually need to go their own way.

[0] https://github.com/peergos/peergos




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: