matheus23.com
Building iroh with the amazing folks at number 0 (n0.computer).
Generally striving to increase user agency and excited about commons networks.
Only works for Canadian CEOs, apparently.
Rust, cryptography, CRDTs & more on my feed
387 posts
391 followers
269 following
Regular Contributor
Active Commenter
comment in response to
post
Deliberately building addiction into an app is unethical. Addiction is the opposite of user-agency.
"Addiction is defined as not having control over doing, taking or using something to the point where it could be harmful to you."
comment in response to
post
Cc @zicklag.dev
comment in response to
post
I'd love to meet you somewhere someday to talk about fun ideas like putting capability tokens (like UCAN) into mTLS (with encrypted ClientHello).
We sort of had this in the Fission days with AWAKE, but never made full use of it (and didn't integrate it deeply with the TLS stack).
comment in response to
post
<0.1% wen
comment in response to
post
I agree having async and sync functions being distinguished is better. In cases like rust this is like literally arguing for separate return types.
That said I still think colored function critiques make sense, because that's not what it's about
comment in response to
post
If I read your take, it kinda sounds like you're saying "function coloring is not the problem", but that depends on your definition. You say even types are differently colored functions, but one could say only non-abstractable properties are "colors".
comment in response to
post
I agree that types can be seen as function coloring.
The biggest problem IMO is that although you can make functions in e.g. js or rust polymorphic when it comes to which type they take, you can't make them polymorphic over whether they are async or not!
This is unlike in haskell with HKT though.
comment in response to
post
I think this is really accurate.
It might be this: plc.surge.sh/gallery
comment in response to
post
Are you comfortable sharing what your treatment entails?
Do you medicate or is it behavioral therapy?
comment in response to
post
As someone familiar with the unison language that can also implements a sync algorithm for syncing between machines this *really* confused me for a second :D
comment in response to
post
I have now 🥲
It is literally the last PLC operation that fails to verify in my set of 38M+ operations.
I haven't looked into it yet. But I have a looming suspicion this one will be harder to figure out 😅
comment in response to
post
Same!! And nobody told me in code review which would mean... (Or maybe it doesn't matter that much to them?)
comment in response to
post
It spells 404 🤍
comment in response to
post
You'll always have this social consensus aspect.
Think the Ethereum/Eth Classic fork.
You cannot fix this. (And maybe one shouldn't want to? After all, perhaps at that point censoring that operation is sensible.)
comment in response to
post
Automating this detection & cross-checking is the next obvious step, and yes it would work in a similar way to what you're describing with the MST.
In practice, I think it'll likely look more like adopting sunlight.dev, but even an append-only BLAKE3 file of operation hashes could be a start.
comment in response to
post
In practice, (1) this will likely be detected, as there are a bunch of PLC directory mirrors out there, and (2) there will likely be some kind of "rough consensus" on what happened that can be gathered via lots of metadata.
comment in response to
post
Even if you grabbed your own copy of that rotation update, Bluesky can claim that your rotation update is invalid because it was nullified within the 72h nullification window.
At this point it'll be one's word against another's, since the operation timestamps aren't signed.
comment in response to
post
Since (practically) every did:plc is initialized with rotation keys controlled by Bluesky, even if you rotate your ledger away from Bluesky's rotation keys, plc.directory can choose to stop serving that rotation update at any time.
comment in response to
post
Maintaining bindings and publishing lots and lots of packages is a lot of work we're not yet set up to do.
We'll reevaluate once we hit 1.0 and APIs are more stable.
At the moment: build application-specific bindings. (And tailor them to your application needs!)
comment in response to
post
Yeah this is correct, and we're aware of that.
In its current form, I would advise a web dev against using this.
I'd like to encourage patterns like e.g. the figma web app -> figma native app.
The web version is very limited. You get the full power with the native version.
comment in response to
post
These look awesome :) My partner is celiac, we have a banana-based recipe that works really well that I'd love to share if you want. But considering how great those look, you might be served well already :D
comment in response to
post
Developer documentation is the shit.
I read it more than the main landing page copy.
I spend hours looking at various projects' documentation getting excited about them!
comment in response to
post
I was thinking more of a way of committing the set of all 38M (and growing) submitted and validated PLC operations so they can't be retroactively omitted.
So a log over all the logs if you will.
comment in response to
post
It's fairly centralized at the moment.
If you initialized your DID with your own key, they can't "fake" records, but they can essentially remove them.
Building certificate logs on top is the next logical step.
comment in response to
post
That operator is a Haskell OG 😀
Have a look at the Haskell Logo:
(refers to the Monad bind operator: hackage.haskell.org/package/base...)
comment in response to
post
@soatok.bsky.social 😅
comment in response to
post
did:plc auditing is a bunch of CPU work:
re-encoding loaded date in dag-cbor, hashing, verifying signatures etc.
Parallelizing this was really easy with #rust scoped threads & crossbeam-channel (I needed an spmc channel to distribute work).
A full audit of ~34M dids now takes ~20mins on my machine
comment in response to
post
Oh and I'm realizing my percentage count is totally off :)
I'm doing <audited dids> / <number of did:plc records> which is obviously wrong (there are multiple records per DID).
So yay it's even faster than I thought!
comment in response to
post
Hehe yeah.
Gives the "vanity" in them even more meaning now, huh?
comment in response to
post
Big thanks to @blebbit.app for the PLC directory pg dump!
comment in response to
post
Fun fact: I'm using @fjallrs.bsky.social for storing & indexing these PLC records. Required storage with some small tricks (15 bytes per did:plc, 32 bytes per CID) ends up being ~13GB.
Which made me think: Hey that easily fits into RAM! And yeah - I added another impl that uses BTreeMaps. Works :)
comment in response to
post
The question is if I can handle vi 👀
comment in response to
post
Well, what else do you do when you need to edit line number... *checks notes* ... 5 million 269 thousand 206?
Uhm, yeah let's try sed.
/me starts writing the command:
sed '5269206s/"at://!@#$%^&*()-=_+[]\\\\{}|;\':\\",./<>?"
Ah fuck this is going to be a fun string escaping puzzle isn't it? 😅
comment in response to
post
Now, me trying to edit my 22GB .jsonl file export of did:plc records...
Tried zed, ended up consuming 22 gigs of ram, and then hung a bit (I'm sure it would've loaded *eventually* but I wasn't keen on waiting).
Vscode just dies.
comment in response to
post
Too late probably, but check this out