1,862 karma · joined September 28, 2016
Also, blocking scraping is very rich (and expectedly hypocritical) for an AI company, which SpaceX is now.
I did want to point out that Matrix does do distributed eventually-consistent authorization, which is their key invention IMHO. (Rooms are distributed among the homeservers, none of which are privileged over the others. You could (and their long-term plan from back in the day) was to run a tiny little single-device homeserver on every device to achieve P2P.)
It's tricky, but a very cool algorithm! Several entities (including myself as a hobby project) are working in combining the Matrix eventually-consistent CRDT with MLS for encryption for a no-compromise distributed E2EE system. It's possible, but very hard, as you might imagine.
Edit: Here's one academic paper writing up the abstract algorithm behind Matrix https://dl.acm.org/doi/10.1145/3381991.3395399
The two methods that seem feasible are making it hard to copy (putting it in the secure element in your phone, for example, which I don't love) or doing tokens that can only be used a limited number of times per day, like in : https://eprint.iacr.org/2006/454
(B) Does not include:
...
(ii) A bot that is a feature of a video game and is limited to
replies related to the video game that cannot discuss topics
related to mental health, self-harm, or sexually explicit content, or
maintain a dialogue on other topics unrelated to the video gameIt's not about copying identical code twice, it's about refactoring similar code into a shared function once you have enough examples to be able to see what the shared core is.
Now if I ever get around to writing that terminal emulator for fun, I'll be tempted to do it with this algorithm for the code's aesthetic appeal.
I really disagree with this article - despite protestation, I feel like their issue is with Yjs, not CRDTs in general.
Namely, their proposed solution:
1. For each document, there is a single authority that holds the source of truth: the document, applied steps, and the current version.
2. A client submits some transactional steps and the lastSeenVersion.
3. If the lastSeenVersion does not match the server’s version, the client must fetch recent changes(lastSeenVersion), rebase its own changes on top, and re-submit.
(3a) If the extra round-trip for rebasing changes is not good enough for you, prosemirror-collab-commit does pretty much the same thing, but it rebases the changes on the authority itself.
Here's a modified version of the steps of their proposed solution:
1. For each document, every participating member holds the document, applied steps, and the current version.
2. A client submits (to the "server" or p2p) some transactional steps and the lastSeenVersion.
3. If the lastSeenVersion does not match the "server"/peer’s version, the client must fetch recent changes(lastSeenVersion). The server still accepts the changes. Both the client and the "server" rebase the changes of one on top of the other. Which one gets rebased on top of the other can be determined by change depth, author id, real-world timestamp, "server" timestamp, whatever. If it's by server timestamp, you get the exact behavior from the article's solution.
CRDTs can store this casual history very efficiently using run-length encoding: diamond-types has done really good work here, with an explanation of their internals here: https://github.com/josephg/diamond-types/blob/master/INTERNA...
In conclusion, the article seems to be really down on CRDTs in general, whereas I would argue that they're really down on Yjs and have written 80+% of a CRDT without meaning to, and would be happier if they finished to 100%. You can still have the exact behavior they have now by using server timestamps when available and falling back to local timestamps that always sort after server timestamps when offline. A 100% casual-history CRDT would also give them much better debugging, since they could replay whatever view of history they want over and over. The only downside is extra storage, which I think diamond-types has shown can be very reasonable.
Matt Levine's Money Stuff has a podcast with his friend and reporter Katie Greifeld, which is a lot of fun chatting about Money Stuff in an informative way.
I go through cycles of being obsessed with Blank Check (which goes through director's filmographies), and often more specifically, The Phantom Podcast (and sequels) where they watched The Phantom Menace over and over again under the guise of it being the only Star Wars movie.
I am actually pitching an alternative though that doesn't seem that out there to me. I'm honestly surprised it isn't already an option in mainstream messengers (or at least Signal).
I think practically you'd want to be able to create time-limited, otherwise uncorrelated invite tokens/addresses that you could freely give out and deactivate later.
All phone calls, SMS, emails, and instant messages should be blocked unless the other party is in my contacts or I have reached out to them first (plus opt-in contact from contacts of contacts, etc). Ideally, cryptographically verified.
I would argue this is the real solution to spam and scamming - why on earth are random people allowed to contact me without my consent? Phone numbers or email addresses being all you need to contact me should be an artifact of an earlier time, just like treating social security numbers as secret.
I realize this isn't super practical to transition existing systems to (though spam warnings on email and calls helps, I suppose, and maybe it could be made opt-in). I dearly hope the next major form of communication works this way, and we eventually leave behind the old methods.
Also, SMS shouldn't be used for 2FA anyway.
If they stopped, I think I would seriously consider swapping banks and whatever else instead of using a different OS.