Canonicalization is easy using the existing CBOR and JCS RFCs (as I noted before), and implementation of JCS is something you might use as a test for a junior dev, because it's such a trivial to write: https://github.com/erdtman/canonicalize/blob/master/lib/canonicalize.js
Yeah, where does it say you need to use anything but plain JSON/JWT? That's the most common variant, and most people choose it because they don't want to process as LD/RDF.
You can use VCs as plain JSON, there's no RDF forced on anything: https://www.w3.org/TR/vc-data-model/#json
But they're using the JWT variant if you look at the docs, not JSON-LD/RDF, and the VCs aren't involved with the app datastore, it's just a thing used for signed proofs completely unrelated to Nostr/social network stuff.
The VCs appear to be orthogonal/separate from any of the app data storage/interaction layer, and I see they primarily use the JWT variant of VCs anyway. The data storage/interaction part is listed as DAG-CBOR, so no RDF involved. But aside from all these protocols there's a simple JSON canonicalization RFC here people should use instead of rolling their own, imo: https://www.rfc-editor.org/rfc/rfc8785
Quick question: I've seen so many inaccurate takes here that are wildly off when I go check out those materials and code they published, so is it possible that there's a sort of highly tribal bias here that's preventing people from being thoughtful in their assessments? I like learning about all these protocols, and find it a bit odd people aren't willing to do so.
Whew, luckily I looked into it and that's not how it works at all. Verifiable Credentials are just a signed proof format where you take a statement about something/person and signing it with your ID's key. No blockchain involved. Pretty cool that's been standardized, and I heard even LinkedIn is accepting VCs for proof of employment now.
Yeah, I'm confused too and asked the same from folks here with no real responses. Why would VCs be posed as a "Nostr killer"? I never heard their team claim that. I think the app data, comms, binary streams, etc. part is what they're calling "DWeb Nodes", something that seems entirely separate from VCs.
Yeah, been asking the same question. Seems like folks are confusing an orthogonal signed credential format that's used outside the system with what looks like a completely separate app/data layer they're calling "DWeb Nodes" , which don't appear to have anything to do with VCs 🤷♂️
I found the link to their reference implementation, and it looks like soon = now, at least for a fair amount of the features from that areweyet site: https://www.npmjs.com/package/@tbd54566975/web5
Also, looks like nothing relies on RDF, so what was all that about again?
Nothing about Web5 relies on RDF, from my understanding of their work, so why are you talking about it?
What could such a 'bridge' look like for them, as you understand the two systems?
Why is what appears to be the Verifiable Credentials portion of that work, which is specific to signed proofs and not the app data layer, being labeled as a "Nostr killer"? Wouldn't the DWeb Node part they talked about be the superset thing that's more related to things Nostr does? Did they talk about anything as a "Nostr killer", or is that some narrative created here/by others?
Is Web5 related to BlueSky? How so? What did they say/show? Is it bad that a tech is aiming to enable a wider set of app use cases?
Social posts are cool, and all these platforms seem capable of that, but if what you say is true, how do I store my medical data encrypted on it and give my primary care physician permissioned access, as well as the ability for him to cryptographically delegate subsequent access to other doctors he needs to? Why would a generalized upgrade to the Web not be easily capable of doing these things in a cohesive way?
Yeah, that's just their own company, to appease legal, etc., but the actual spec is developed in an open source standards org, so any particular company's website isn't really relevant to the body of work outside the open source orgs.
Are you suggesting a VC is used as a tag system for the data records? Think VCs are rather separate, and nothing about the system/VCs relies on JSON-LD, so perhaps you can clarify?
I think most of them use Macs, so does a thing working across OSes (as one would expect for the Web) make it bad? Is Linux bad because Microsoft has been among its top 5 code contributors for the better part of a decade?
Now I'm thinking it would be better if each of these attestations was its own long-living event, so each identity proof could live by itself and we could even get a history of external identities. nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj
Chrome and Android are adopting Verifiable Credentials, the same standard LinkedIn and Microsoft have adopted, so why not just adopt that to be compatible with the rest of the world?
TLDR: anyone who says "I can provide a non-interactive proof of current state for a mutable record in an oracle without consulting said oracle", is trying to sell you magic beans, because that is quite literally impossible.

