HackerLangs
TopNewTrendsCommentsPastAskShowJobs

miloignis

1,813 karmajoined hace 10 años

comments

miloignis
·ayer·discuss
Neat, thanks for the writeup! I think a single creator-admin for small groups is a nice, simple, and practical design point.

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
miloignis
·anteayer·discuss
Lobste.rs is very much still active, more than ever I think. They have a `vibecoding` tag that you can remove from your page, if you'd like.
miloignis
·hace 8 días·discuss
This has been discussed before, and I believe the general consensus is that djb's objections don't make sense. The Key Material blog addresses this in a very good larger ML-KEM mythbusting post: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:te...
miloignis
·hace 16 días·discuss
I recently bought an X4, put crosspoint on it, and have been loving it. I've been reading so much more than before, just because it's always available on the back of my phone.
miloignis
·el mes pasado·discuss
What do you mean? The HF checkpoint is linked from the blog post you sent: https://huggingface.co/XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash
miloignis
·el mes pasado·discuss
The article is talking about "Kernel" as in a low level piece of code to compute math, in this case extended attention for running LLMs on a GPU or accelerator, not as in the Linux Kernel.
miloignis
·hace 2 meses·discuss
Matthew Green talks about this in his blog on the subject: https://blog.cryptographyengineering.com/2026/03/02/anonymou...

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
miloignis
·hace 3 meses·discuss
As I posted at top level, they've already backed off, but even the linked version had a carve out for video games:

  (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 game
miloignis
·hace 3 meses·discuss
As some of the reddit comments point out, they've already backed off: https://www.wjhl.com/news/tennessee-backs-off-sweeping-artif...
miloignis
·hace 3 meses·discuss
Arguably, that's wrong - not because it's unsafe, but because it's not the best temperature for any part of the chicken I know of. I'm a big J. Kenji López-Alt and Serious Eats fan, and 165 is too hot for good chicken breast and too cool for good dark meat: https://www.seriouseats.com/chicken-thigh-temperature-techni...
miloignis
·hace 4 meses·discuss
The rest of the article shows exactly how a CRDT is a sound base for a version control system, with "conflicts" and all.
miloignis
·hace 4 meses·discuss
I really think something like Xet is a better idea to augment Git than LFS, though it seems to pretty much only be used by HuggingFace for ML model storage, and I think their git plugin was deprecated? Too bad if it ends up only serving the HuggingFace niche.
miloignis
·hace 4 meses·discuss
Of course, the rule of 3 is saying that you often _can't tell_ what the shared concept between different instances is until you have at least 3 examples.

It'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.
miloignis
·hace 4 meses·discuss
This is wonderful news, and my sincere thanks to the author. I remember coming upon this algorithm several years ago, and thinking it was extremely elegant and very appealing, but being disappointed by the patent status making it unusable for FOSS work. I really appreciate the author's choice to dedicate it to the public domain after a reasonable amount of time, and congratulations on the success it had while proprietary!

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.
miloignis
·hace 4 meses·discuss
(Xpost from my lobsters comment since the Author's active over here):

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.
This is 80% to a CRDT all by itself! Step 3 there, "rebase its own changes on top" is doing a lot of work and is essentially the core merge function of a CRDT. Also, the steps needed to get the rest of the way to a full CRDT is the solution to their logging woes: tracking every change and its causal history, which is exactly what is needed to exactly re-run any failing trace and debug it.

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.
If you store the casual history of each change, you can also replay the history of the document and how every client sees the document change, exactly as it happened. This is the perfect debugging tool!

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.
miloignis
·hace 4 meses·discuss
No, the devices GrapheneOS supports won't be out until 2027 (and may only be the flagship models?)
miloignis
·hace 4 meses·discuss
I'm big into DnD podcasts, so Dragon Friends (Australian comedians doing DnD), The Adventure Zone (McElroy boys & dad doing DnD), Not Another DnD Podcast, etc.

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.
miloignis
·hace 5 meses·discuss
For sure, getting rid of money would help if we had an alternative.

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).
miloignis
·hace 5 meses·discuss
Ah, I should have elaborated a bit more - the strict solution is out-of-band only, namely in person or allowing contacts-of-contacts to reach out.

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.
miloignis
·hace 5 meses·discuss
I have a radical solution - it should not be possible to contact someone unsolicited.

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.