Replying to @ChristopherA
Also at the meeting, we’ll be looking at how Gordian technology can improve digital identity. I’ll be presenting on using Gordian Sealed Transaction Protocol (GSTP) to create MuSig 2 signatures securely. [4/7]
Replying to @ChristopherA
Speaking of identity, I hope you’ll also read an article I wrote for #IIW on whether self-sovereign identity (#SSI) #is now failing its foundational aspirations. [3/7] https://www.blockchaincommons.com/musings/musings-ssi-bankruptcy/
Replying to @ChristopherA
My feature presentation will be on Edge Identifiers & Cliques, a new relational sort of identity that I’ve written about in recent articles. TL;DR? What if identity were about our connections & communities? [2/7] https://www.blockchaincommons.com/musings/musings-cliques-1/
Next Wednesday, @BlockchainComns will be holding a meeting on a topic that I’ve long advocated for: safe digital identifiers. It’s at 10am PST, and if you’re interested in the future of identity, I hope you’ll attend. [1/7] https://github.com/BlockchainCommons/Gordian-Developer-Community/blob/master/meetings/identifier-meeting.md
Replying to @ChristopherA
There’s hasn’t previously been a huge focus on identity at @BlockchainComns primarily because none of our patrons were in the space. If you’d like to work with me on making digital identity safer, talk to me about becoming a sponsor! [7/7]
Replying to @ChristopherA
We’ve come a long ways from specing out DIDs at Rebooting the Web of Trust, but there are still many exciting futures for identity and identifiers. Join me next Wednesday to talk about some of them! [6/7] https://github.com/BlockchainCommons/Gordian-Developer-Community/blob/master/meetings/identifier-meeting.md
Replying to @ChristopherA
Our lead researcher @WolfMcNally will be presenting on using Gordian Envelope to create a DID-like identifier we’re calling a XID, which has unique advantages due to Envelope’s elision capabilities. [5/7] https://developer.blockchaincommons.com/xid/
RT @jesseposner: Check out our new Bitkey whitepaper where we leverage FROST, OPRFs, TEEs, Pedersen commitments, and blind signatures to de…
Monetization is important, but not it it compromises our principles, and then risk being insufficiently differentiated from mDL and federations: https://www.linkedin.com/pulse/has-our-ssi-ecosystem-become-morally-bankrupt-christopher-allen-ysjjc https://twitter.com/tang_talks/status/1851387134953095216
Pleased MuSig2 has advanced to a tagged release. We plan on talking about MuSig2 this Wednesday at Gordian Developer meeting (10am PST). In particular, I have been puzzling out a sequence diagram for how a trustless hub can be used to facilitate 3:3, 4:4, + peers (2:2 is easy)… https://twitter.com/n1ckler/status/1853492564705366029
Replying to @ChristopherA
Details on this Wednesday’s Gordian Meeting:
https://x.com/ChristopherA/status/1852404335004790964
Replying to @ChristopherA
We also have a new developer page dedicated to MuSig2: https://developer.blockchaincommons.com/musig/
This event for digital wallet devs on a new kind of decentralized identifier, edge identifiers & cliques using MuSig2 & FROST, is tomorrow morning at 10am PST. If you are attending from overseas, the US just changed our clocks, so double check your time zone conversion. https://twitter.com/ChristopherA/status/1852404335004790964
Interested in group signatures, such MuSig2? Worried about the risks of correlation of public keys used as identifiers? We’ll be talking about this and more in 10 minutes at our Gordian Developer Meeting. https://twitter.com/ChristopherA/status/1853994414764626137
Replying to @ChristopherA
Why focus on identifiers? Our modern internet technologies require them, yet every identifier is also a risk of correlation to personal identity. Every Lightning node is has a persistent identifier, every NOSTR node. They all can be risky to human rights. [2/10]
The @BlockchainComns meeting this month focused on identifiers: in particular a new form of decentralized identifier; our new clique identifiers, and MuSig2 signatures (which can enable both edge identifiers & cliques). [1/9] https://github.com/BlockchainCommons/Gordian-Developer-Community/tree/master/meetings#detailed-list-of-meeting-summaries-with-archives-of-video-mp3-and-transcripts
Replying to @ChristopherA
The key benefit of XIDs? Elision! You can just reveal some of the keys, endpoints, or other data that a DID Controller Document contains and release the rest, only if it’s needed, through progressive trust. Many points of potential correlation can be hidden. [4/10]
Replying to @ChristopherA
Our first presentation was on XIDs, a new sort of decentralized identifier built on Gordian Envelope. It builds on the work I did for the W3C on Decentralized Identifiers (DIDs), but has capabilities that DIDs do not. [3/10] https://www.youtube.com/watch?v=lKVp5WzBZD4
Replying to @ChristopherA
Cliques are built with Schnorr signatures. A first look at how we can create a MuSig2 signature to support cliques, taproot, etc. was thus our third and final presentation for the day. [7/10] https://www.youtube.com/watch?v=FaNypFsGczg
Replying to @ChristopherA
Relational identifiers of this sort can better model the way that identity actually works, and can also help reduce single points of failure and compromise. You need to be able to keep your digital identity. Cliques can help you do so. [6/10]
Replying to @ChristopherA
The second presentation was on Edge Identifiers & Cliques. This is a new paradigm leveraging protocols like MuSig2 and FROST to create identifiers based on relationships [5/10] https://www.youtube.com/watch?v=EFHvyrUj7Kk
Replying to @ChristopherA
The next Gordian Developer Meeting will have presentations to help wallet developers to integrate FROST in 2025. It’s on Dec. 4th. If you’re a wallet developer, sign up for our announcement list to get the complete info on the meeting! [10/10] https://www.blockchaincommons.com/subscribe/
Replying to @ChristopherA
Though I’ve worked with identity for the last decade, including work on both the W3C DID and VC standards, it’s a fairly new topic for @BlockchainComns. We’re looking for sponsors interested in continuing the work. If that’s you, drop me a line! [9/10]
Replying to @ChristopherA
A two-person MuSig2 is easy enough, but it starts to get trickier when you want to create a 3-of-3. The presentation talked about how to do so using Gordian Envelope’s GSTP and leveraging trustless coordinator [8/10]
👍”This session was an important reminder for me—and for all of us in this space—not to lose sight of the vision and principles that brought us here. Even as we navigate complex environments, we must stay grounded in the values that underpin SSI, ensuring they remain central as… https://twitter.com/mathieu_glaude/status/1854542188899676408
Replying to @ChristopherA
My blog post on this topic is at https://www.lifewithalacrity.com/article/ssi-bankruptcy/
Replying to @ChristopherA
Or if you prefer LinkedIn: https://www.linkedin.com/pulse/has-our-ssi-ecosystem-become-morally-bankrupt-christopher-allen-ysjjc/
Thanks for the invitation to speak at the W3C Credentials Community Group. https://twitter.com/tang_talks/status/1854985470624801059
Replying to @ChristopherA
cc/@decentralgabe @csuwildcat
Jack Dorsey’s #Block may be winding down #TBD and #Web5 efforts, but there are some good ideas worth preserving. I particularly like the idea of sharing decentralized documents to bootstrap #SSI via BitTorrent’s mainline DHT. There is a limit of 1K, but that is perfect for XIDs…
Replying to @csuwildcat
I definitely like personal datastores. I hope somehow it will be one of many kinds of endpoints (elided for privacy) that you can choose to commit to in a decentralized way and share when needed.
RT @WolfMcNally: Very proud of my ongoing work with @BlockchainComns. We recently introduced the concept of Extensible Identifiers (XIDs),…
Replying to @getpubky
For 10 years now in the #SSI community we’ve been trying to move away from identifiers based on public keys, unless they are revocable, rotatable, and delegatable. W3C DIDs don’t mandate this, but should.
Here’s how you can do it with XIDs: https://youtu.be/lKVp5WzBZD4
Replying to @ChristopherA
Here is a sequence diagram that shows it is fairly easy to do peer-based MuSig2, as is trivial to create and authenticate a secure channel between two peers. However, for 3 more parties, using a trustless facilitator, it is harder: https://developer.blockchaincommons.com/musig/sequence/ [3/10]
Replying to @ChristopherA
Here our root webpage about MuSig2 (and its variants) https://developer.blockchaincommons.com/musig/ [2/10]
I’m pleased to hear that some real-world implementations begin to leverage the power of group signatures using MuSig2 in taproot on Bitcoin.
Doing 2-of-2 MuSig is relatively easy, but I’ve been puzzled on how to do 3-of-3 or more with a trustless facilitator. Thread 🧵 follows:… https://twitter.com/salvatoshi/status/1854523120335323137
Replying to @ChristopherA
I have a short video about this sequence diagram and my puzzling of how to create a trustless coordinator for larger group signatures: https://youtu.be/FaNypFsGczg [5/10]
Replying to @ChristopherA
Why is 3-of-3+ important? You can have as many signature conditions as you want in the hidden taproot tree, but for the non-hidden base public key, it ideally should be a unanimous aggregate public key of all the parties involved in the transaction. [4/10]
Replying to @ChristopherA
If you are interested in these topics, I encourage you to join the Gordian Developer Community where a number of digital asset wallet developers are working on interoperable standards. [8/10]
Replying to @ChristopherA
MuSig2 is also useful for other ideas, including various new forms of relational and group identity that have some resilience advantages. TL;DR? What if identity were about our connections & communities? https://www.youtube.com/watch?v=EFHvyrUj7Kk [7/10]
Replying to @ChristopherA
Not even discussed here in these diagrams are the UX issues (I’m not talking about UI, but the human experience side). Who proposes the transaction and when? A nonce commitment can be created without knowing what is signed, should support that or stop that? What if someone wants…
Replying to @ChristopherA
If you find our work at @BlockchainComns valuable, become a sponsor. We need your patronage so that we’ll be around to bring in the next wave of innovation! https://github.com/sponsors/BlockchainCommons [10/10]
Replying to @ChristopherA
Our meeting next month is on FROST (another multisig approach), but we plan to have one in early 2025 dedicated to MuSig2 interoperability issues. Sign up to receive announcements about future meetings at https://www.blockchaincommons.com/subscribe/ [9/10]
Replying to @salvatoshi and @achow101
Replying to @salvatoshi
I presume now that MuSig2 is in a tagged release of libsecp256k1 that it will be included in the rust wrapper for it soon. This was about a month based on another change this year we needed in libsecp256k1 that took about a month. We need it for our codebase too.
Replying to @philiprosedale
https://x.com/christophera/status/1242941221850529797 https://twitter.com/ChristopherA/status/1242941221850529797
Replying to @philiprosedale
https://x.com/christophera/status/1243413128378892293 https://twitter.com/ChristopherA/status/1243413128378892293
Replying to @philiprosedale
Yes. You can use ZK range proofs (similar to the Liquid blockchain uses) to prove you are nearby in a privacy preserving way.
Replying to @philiprosedale
https://x.com/christophera/status/1615138869695090690 https://twitter.com/ChristopherA/status/1615138869695090690
Replying to @philiprosedale
I never implemented it, but I’ve talked with a number of people about it, and it is feasible. I posted it here years ago so no one could patent it.
Replying to @philiprosedale
Then just send three words via signal. Here is a spot on north side of Coit Tower: ///bleak.fever.talent
Replying to @philiprosedale
The is little better than Signal for E2E, so if you trust the other party, just use that. There are versions of what3words that don’t send out your GPS coordinates.
Replying to @philiprosedale
My idea is more for scenarios that require less trust. For instance, “Shall we play…” matching for sports, games, music, etc. You find out who in rough area has similar interests and time availability, chat, and then if all checks out, trust an actual location and time.
Replying to @ankurb and @jessepollak
https://x.com/ottomorac/status/1851420098365702241 https://twitter.com/ottomorac/status/1851420098365702241
Replying to @ankurb and @jessepollak
https://www.blockchaincommons.com/musings/musings-ssi-bankruptcy/
RT @resistancemoney: What follows? Unclear. But the next time someone asks you to give money to @btcpolicyorg , @HRF, localhost, core devel…
Replying to @philiprosedale
There are others that do decent E2E, so keeping the layers separate and heterogeneous is advantageous. You can use same approach over several and not have to change it. Maintaining a secure E2E client isn’t trivial, and also a duplication of effort given several exist.
🔍👀 https://twitter.com/decentralgabe/status/1856418472823271889
Replying to @ChristopherA
It’s my newest article on “Progressive Trust”, a topic that I’ve been writing about for over two decades. [2/11] https://buff.ly/4fNi0YC
In real life, we extend trust gradually, slowly learning about people we’re interacting with & revealing more of ourself in the process. Why don’t we do that in the digital world? That’s the topic of “Building Trust in Gradients”, today’s Musings. [1/11] https://buff.ly/3CmcVYU
Replying to @ChristopherA
Now we have the opportunity to rewrite trust on the internet using decentralized technologies such as DIDs and clique identifiers. We can design Progressive Trust that models how trust actually works in real-life, where we reveal things a bit at a time. [4/11]
Replying to @ChristopherA
The short answer for “why” digital trust is binary is that tech giants have centralized trust by turning it into a binary choice: trust a certificate or not; block a user or not. That’s not how trust has worked for thousands of years. [3/11]
Replying to @ChristopherA
“Building Trust in Gradients” also attempts to lay out a foundation for a language of trust. Validation. Verification. Authentication. Proof. What do they all means? Here’s one set of consistent answers. [7/11]
Replying to @ChristopherA
By adapting the life cycle of progressive trust as it exits in physical reality to trust in the digital world, we can create a solid foundation for reimagining how critical personal interactions can be successful online. [6/11]
Replying to @ChristopherA
But that raises another question: what does a model of real-world trust really look like? That’s what today’s article, “Building Trust in Gradients” tries to tease out. [5/11] https://buff.ly/3CmcVYU
Replying to @ChristopherA
“Building Trust in Gradients” summarizes this crucial life cycle from a longer article that focuses even more on the language of trust and its origins. It’s available on the @BlockchainComns developer website. [9/11] https://buff.ly/3YPUCDa
Replying to @ChristopherA
Context, Introduction, Wholeness, Proofs, References, Requirements, Approval, Agreement, Fulfillment, Escalation, and Dispute form a whole life cycle of trust (with some of that stuff, such as Dispute, being thankfully optional). [8/11]
Replying to @BlockchainComns
If you’re interested in working on a progressive-trust system, drop me a line. I currently have executive consulting time available and would love to see a signal that @BlockchainComns should focus more on the topic. [11/11]
Replying to @BlockchainComns
I’d love to talk about Progressive Trust and its life cycle and how our understanding of it can be improved, as well as how we can better standardize our usage of some of these tricky words! [10/11]
I’ve noticed that many of our community has moved to BlueSky. You can find me there at https://bsky.app/profile/christophera.bsky.social/. I plan to cross-post there and on LinkedIn my more important posts and links.
RT @jamesob: THE CONSENSUS CONUNDRUM
Bitcoin faces a one-of-a-kind leadership problem
—
A lot of consensus-change proposals for bitcoin…