/ is on Nostr

Public Key

npub10p8rnhp6m8g3hlc2rsgmxlyp5kxxfcfaz7mk5lwmqnz9u40llmhqsvggyw

Profile Code

nprofile1qqs8sn3emsadn5gmlu9pcydn0jq6trryuy730dm20hdsf3z72hllamspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsu3d4qn

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub10p8rnhp6m8g3hlc2rsgmxlyp5kxxfcfaz7mk5lwmqnz9u40llmhqsvggyw

Show more details

Last Notes

2023-05-21 18:25:43

- reply

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

2023-05-21 18:18:12

- reply

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.

2023-05-21 16:46:01

- reply

You can use VCs as plain JSON, there's no RDF forced on anything: https://www.w3.org/TR/vc-data-model/#json

2023-05-21 16:42:40

- reply

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.

2023-05-21 15:02:01

- reply

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

2023-05-21 13:38:56

- reply

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.

2023-05-21 13:33:40

- reply

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.

2023-05-21 13:30:56

- reply

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.

2023-05-21 13:27:24

- reply

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 🤷‍♂️

2023-05-21 13:23:19

- reply

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?

2023-05-21 13:05:42

- reply

Nothing about Web5 relies on RDF, from my understanding of their work, so why are you talking about it?

2023-05-21 11:42:22

- reply

What could such a 'bridge' look like for them, as you understand the two systems?

2023-05-21 11:40:30

- reply

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?

2023-05-21 11:34:27

- reply

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?

2023-05-21 11:30:10

- reply

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?

2023-05-21 11:24:26

- reply

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.

2023-05-21 11:21:46

- reply

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?

2023-05-21 11:17:42

- reply

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?

2023-04-25 13:46:44

- reply

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?

2023-03-20 12:52:52

- reply

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.

2023-03-20 02:10:37

- reply

You could certainly get proofs from ION, as it contains all the data for them, but just hasn't been implemented yet. The issue with literally any construction, even L1 blockchain ones, is that you really must run some sort of light node to avoid Tip - N state issues.

2023-03-19 23:49:44

- reply

Running an ION light node (a configuration that's provided for in the system, but has yet to be coded to provide) reduces the resource requirement by ~95%, making it feasible for users to run on most devices.

2023-03-19 23:24:05

- reply

To own or take someone's ID string, you'd literally need to take control of their current recovery private keys, you can't Sybil your way to that.

2023-03-19 23:22:41

- reply

Part of your confusion seems to stem from the idea that IDs are something you can register like an ENS/DNS name, wherein different people could end up with a string attributed to them. ION specifically removes this whole class of issues due to its self-certifying inception event for creation of IDs, and it's non-transferability properties.

2023-03-19 23:20:55

- reply

*works

2023-03-19 23:20:31

- reply

That's not how creation and ownership of ION IDs worlds. You cannot attempt to create/own the same ID as another person, because the ID itself is entirely generated by the initial state of the IDs PKI (including the keys). This cryptographically secure, unique, immutable means of creating identifiers is know as a 'self-certifying inception event'.
Because all data related to DIDs in ION is DID-relative, and you cannot Sybil/own another person's IDs, your routing and data URLs are not susceptible to the type of issue you are describing.