I'm not very familiar with the service, but AFAIK they don't. It would be great if they added it.
EDIT: It looks like it might, from the front page, I will try it out to make sure. If it does, that'll be great!
EDIT 2: It sort of does, but it's on a per-key basis, not an entire identity. You can publish proof on Twitter/Github/whatever, but it's only for one specific key, and it's one key per service, which means you can't only have one identity and multiple services.
Who said the keys need to be long lived in WKD? WKD just makes the key discovery easier based on email address, you can rotate your key as often as you want (just set the expiry date so clients check it).
Also, I'm not sure if I get the "public ledger" part as WKD I just your own HTTPS server. It doesn't have anything in common with keyservers.
In addition to gibsonf1's recommendations (not books), the following books are good. The first 2 are more pure introductions to the math, the third is applying it to physics, the fourth to CS.
This is not the only example. I never ceases to amaze me that Google dropped XMPP because of non-mobile-friendliness and it was proven wrong by a single developer (see: Conversations.im).
It seems in a lot of cases Google just want to go on an easy route of creating fake "standards" (AMP) instead of long way of working with broader community for common good.
Maybe that's just me but the Google I remember back when Android was announced and the company it has become now it's like two totally different entities.
> The people who had been using it would continue uninterrupted.
I'm not sure about that. If the main matrix server disappeared today that'd be problematic. Yes, you'd have history locally but the same can be said for any native client that stores history locally.
As far as I know there is no way to migrate matrix history now. Is there? (genuinely curious)
> I'm not sure about that. If the main matrix server disappeared today that'd be problematic
This ^^
Currently a large amount of users (I'm told around a half, but I'm not sure) have matrix.org as their home server. So Matrix is effectively building a power-law network with all its drawbacks: when the "power node" of the network goes down the whole network falls apart.
To be fair, this is somewhat inevitable in the initial stages, before a reasonable spec is released. Many people, like me, are just "sitting on the fence" and test-driving Matrix via their matrix.org server, until there are reasonable assurances that deploying our own Matrix server will come without too much hassle.
After Synapse 1.0 is released (sometimes next month, IIRC), I'm definitely deploying my own homeserver, and federating it with the rest of the world.
FWIW, I've been running Synapse since 0.20 or so (for at least 2 years now), and there has never been a breaking change in the protocol as far as I'm aware. I had to read release notes at some points to get the upgrade to work, but it was mostly Python-library-related stuff IIRC.
Well they are making one big instance nothing else. Also unfortunately it means that you can't possibly federate with matrix.org. I've been running small otherwise perfectly functioning instance for few years for my circle/work as slack alternative on small vps. One time i did the amazing mistake of turning on federation with matrix.org. It immediately killed my servers performance especially when i joined some popular channel. The channels probably have more messages than my whole server combined. And it works the other way too - matrix.org is like sponge sucking other instances.
I guess this is the real problem for me - i would love to federate but i can't possibly police or enforce what servers/channels are small enough that my users can join them.
This isn’t anything to do with the size of the matrix.org server; just that synapse needs to be more resource efficient and we need to limit the sizes of rooms small servers try to join. we are doing both.
