Do you also think that the go crypto packages are a bit hard to use? What about my attempt at a thin ergonomic layer? github.com/MetaMask/go-...
Details and rationals in the Readme.
It's public if you want to play with it: cad.onshape.com/documents/04...
exploded view of the tenons/mortises of a shoji
full view of a shoji in CAD
I'm opening a new personal tech tree!
Today, some CAD for a shoji (japanese sliding door). It's all parametric so I can adjust the global parameters (dimensions, kumiko counts, ...) and all the cuts, mortises, tenons are recomputed.
Now the questions will be: can I make it for real?
For fun and giggles, I wrote an implementation of IBLTs, for set reconciliation: github.com/MichaelMure/...
Feedback welcome.
Cool list :-)
I'll take the occasion to ask a slightly different question: what do you think is the paper (recent or not) with the most practical potential, to do something better or novel? In particular in the realm of protocols, but feel free to extend further.
Hey @expede.wtf @b5.bsky.social, I enjoyed the Rateless IBLT reconciliation paper. Any suggestion for a mind-bending christmas paper read?
I wrote maybe half of the decoding of an #automerge document in go, as an exercice in performance and database-like internals (column storage, RLE..).
It's sitting in a private repo until I come back to it, but happy to share with a foss license if there is interest. Just ping me.
Another cool thing is that because all the crypto and DID verification methods included, it's quite easy to add more DID types. Implementing did:web took 2h.
The hard part was to figure out that the examples in the spec are invalid.
This crypto package could be split into its own thing if there is interest. Do you think that's useful standalone?
In particular, it contains all the cryptographic handling to make it dead easy to consume DIDs, validate signatures and so on.
If you tried to use different key types with the go standard crypto library, you know it's a minefield of mismatched API.
github.com/MetaMask/go-... fix it.
Another new thing: github.com/MetaMask/go-...
It's a fast and simple (battery included) Decentralized Identifier implementation in go.
Currently it supports did:key, did:web and did:plc.
It's time to announce properly some new things!
I just published v1.0.0 of github.com/ucan-wg/go-v..., the multiformat for cryptographic signatures. It's notably used in UCAN.
This could also be used to explain a codebase:
- start from some entry point question
- get a break down of the data flow or call graph
- click around to get more details
- asks more about language feature, pattern, capability, dependencies ...
Recursive hierarchical explainer for LLMs: starts with a high level concept ("explain database") and get a breakdown. From there you get an UX to expand as deep as you like on sub-topics ("LSM trees") in various ways: more explainers, implementation, connective question...
Does that exists?
Disclaimer: no idea if that actually makes sense.
I suppose the high dimentionality would make the index less compact, but maybe techniques like principal component analysis could compress that space, yet retain enough information for full-text search?
Random thought: full text search engine use word transformation, canonicalisation to map the input text to some internal index (my understanding).
Could a LLM vector space be used instead? That would remove the need for the transformations, and make it work cross-language.
Don't tell anyone, but my secret endeavor is to one day teach something to @expede.wtf instead of being schooled every time (which I enjoy dearly).
Funny that we reconnect like that. Thanks @bmann.ca for being that social catalyst once again!
> Excited to try this.
> This is incredibly cool. I love seeing local first software starting to make a comeback.
> I've been yelling 'omg why doesn't someone build [...] for YEARS. This is wildly exciting.
More than coffee, those are what feed an open source project.
Hehe, git-bug making some waves again on hacker news: news.ycombinator.com/item?id=4397...
I'm not too familiar with it (yet), but why not use Verifiable Credentials, that comes often in DID systems and is heavily standardized, instead of rolling your own format? As I understand it's more or less the same thing: a signed claim.
There is also a token container (with a spec) that abstract the encoding and optional compression. Great to fit into a HTTP header or other medium.
FYI, I have some tooling around go-ucan to apply UCAN policies on HTTP request parameters (host, path, query ...) or JSON-RPC ... that I plan to migrate into go-ucan. The idea is to have a somewhat standard way to apply UCAN on pre-existing HTTP APIs. It'd be great to be all on the same page.
Definitely agree on the "centralized" aspect.
About the certificate logs, as did:plc has a chain of signed operations containing all the data ... isn't that already a certificate log? Could you expand your thought?
Very interesting :-)
I'm on a slow quest to figure out a better DID system + social graph (if there is such a thing to begin with). As you are deep in there, is there something you would do differently?
You wouldn't nees those external scope definitions. You also get delegation for free, which enable some cool use cases.
A very different design for sure though, with different tradeoffs.
I found that a regular first leg of OAuth (social login up to getting the identity token) with a token exchange giving a UCAN token (instead of JWT) is a pretty powerful pattern.
Then you can apply the UCAN policies on HTTP parameters (path, arguments...).
Not necessarily a question for you but I'm wondering .. how much of that is portable beyond ATProto or Bluesky? The ideal identity system should be an agnostic base layer that works everywhere.
About the reputation, it seems that @cred.blue compute a score based on public data. I was more thinking about a reputation system where user actively vet others, or report bad behavior.
Ideally in a distributed fashion, where the score is "local" (your contact weight more on the score).
