jeremie

While did:plc was intended to be centralised from the start and under open governance (https://docs.bsky.app/blog/plc-directory-org), did: provided a framework to adopt other key resolution methods.

As part of the IETF work (https://docs.bsky.app/blog/taking-at-to-ietf) this is a hotly debated area and I’d expect some solid evolution to happen as part of that process, super encourage anyone interested to get involved there!

It was a different era 15 years ago, made some decent inroads on an API based approach with the Locker Project https://en.wikipedia.org/wiki/Locker_(software) but the platforms quickly started gimping the APIs and exports/takeouts were non-existent or too early yet back then, so ran out of steam.

Thanks for making this, def will be digging in!

I picked XML for Jabber in 1998, and at that time I think it was the best choice :)

I’m one of the (independent) board members of Bluesky and I can say with confidence that I don’t have any of these concerns, everyone involved is deeply aligned to the PBC’s purpose of “To develop and drive large-scale adoption of technologies for open and decentralized public conversation.”

Great memories! Back in ‘98 I found a floppy with my original 1994 Netscape Mosaic v 0.93 Beta and shared a bunch of tidbits about it on my personal site (thank you Internet Archive!):

https://web.archive.org/web/20010430044121/http://www.jeremi...

Posted it to slashdot at the time too, I miss those green colors ;)

https://slashdot.org/story/98/10/28/1923205/original-netscap...

I am also on the Bluesky board, and while the original funding did come from Twitter (at Jack’s direction), the company has no control over Bluesky and it is 100% independent.

I do deny it; or to be clear, I think it is a story that we've been conditioned to prefer over the others

Speaking personally, and perhaps it is indeed my conditioning, but at 25+ years of marriage I am living that beauty in 1 every day and I know without a doubt it has led me to my best possible life.

This should be v0.1 based on the actual utility of the spec, just because it's been incubated for so long doesn't magically make it useful.

DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture?

All of the suggested "workarounds" to layer on privacy to DIDs are just lip service in the spec, there's zero technical requirements for an implementation.

I worry that DIDs based on this spec will be deeply harmful if widely deployed with the multiple layers of abstraction, required dependencies on massively complex things like JSON-LD, and abundance of implementation-time choices. It's such an easy "spec" to embrace and extend by big tech, it has no teeth to prevent tracking abuse and it should develop those as hard normative implementation MUSTs before v1.0 versus the non-normative "Privacy _Considerations_" it has now.

Identity is too important to have it done wrong.

I’d say that it feels like just yesterday, but it totally feels like decades ago :)

I’m very lucky to still be close with so may of the truly amazing individuals that helped build Jabber, and over the years deeply honored by all those that spoke to me about how it inspired them.

While at the surface it may seem like all of our efforts had little impact on the big “messaging silos”, I am most proud of how much Jabber/XMPP has made it easy for anyone to build/host/extend a messaging and presence service. Twenty years ago the concepts and architectures were opaque, now they’re commonplace.

Happy Birthday!

As part of telehash v3, we've separated out most of the crypto/handshake packeting into E3X, which has a lot of similarities to QUIC: https://github.com/telehash/telehash.org/blob/master/v3/e3x/...

Personally I have a much broader use case in mind for E3X than QUIC is designed for, incorporating IoT and meta-transport / end-to-end private communication channels. So, I expect they'll diverge more as they both evolve...

I'm a big believer in a (local/p2p) transport encryption mechanism /in addition to/ one for auth, and for it to be transparent to any UX... that's very much our goals for telehash v3 :)

I've been on both sides of dizzyd's interview process and highly respect it, he should be a mentor to other software engineering managers on how to improve their hiring practices.

It would be nice if the README mentioned it was originally based on my https://github.com/quartzjer/js0n :)

I'm leading an effort for a pretty large refactor and cleanup of all of the existing telehash work (look at the commit history), honing in our mission and simplifying it's usability.

We're trying to make it easy for any developer to add/use end-to-end networking that has strong encryption and connectivity built in.

It is indeed in the process of being refactored, to make it easier to adopt and use in parts.

A pretty relevant article about what myself and temas are working on now: http://www.theverge.com/2013/12/4/5173726/you-have-too-many-...

IMO, interop/federation is going to be a tremendous long-term effort and include many standards, but is definitely feasible, inevitable even. There's a lot of innovation happening in messaging again thanks to mobile, we just need to start taking the best of what we've all learned already and work together to improve everyone's stack collectively.

Pumped about this as well, it's the perfect packaging to quickly experiment with distributed sensor grids and be affordable to a hobbyist... pretty sure we'll see some cool "green" gardening (optimized watering), thermal/heating/cooling, power usage, farm monitoring, all sorts of great things built on this!

Is there decent CoAP implementations? That's unfortunately one of the big stumbling blocks with universal p2p transport yet :/

With a telehash style distributed messaging bus you'd need to have clients opt in to centralized reporting and analytics providers, like the library of congress, internet archive, even commercial firehose companies like gnip, etc.

These are not my thoughts, but found them interesting and worth sharing...

It's a little on the young side yet, and I have to prove out some of the apps/demos of it at scale, but it's coming along very nicely and shows a lot of promise.

Ultimately it's a public DHT that enables apps to punch through the NATs (to go direct device-to-device) and talk JSON to each other. It doesn't solve all the problems you face being distributed, but it's a good start :)

I've done my best so far to reduce it to it's most minimal required components to just get the job done, and in the last six months it's slimmed down significantly already, not sure much more can get cut out.

My plan is to get some standard libs and utils written next to hide the frustrating complexity required to build this mesh with peers and proxy the chaos-management for apps.

Exactly, it's the only option left in order to let apps talk directly across the unwieldily myriad of network configurations (NATs).