Aaron Parecki

I was about to ask you about Zion and went and looked it up and boom DWN guide.getzion.com/how-does-zion-…

Yeah I was concerned about that, it’s like we need a blind index ledger that runs in the cloud. I do know some folks that worked on blind index tools for gmail but not in our world. Here is an Encrypted decentralized SPARQL query paper ceur-ws.org/Vol-1121/privo…

ION can be used without doing a Bitcoin txn, so it effectively acts as a richer DID Key with the full set of features the DID spec offers. My point about ION was more that even when you use LD as it was defined, its own acolytes have gotcha-esque gripes about its usage/complexity

@csuwildcat That wasn’t directed at you, I appreciate your work on Ion. I am definitely a fan of the project and recommend it daily. I am curious on the recommendations for new did assignment, examples of temporary did:key while the PoW takes time to reconcile.

Many are working on it, including MongoDB, but it multiplies (or even magnitude shifts) resource consumption, battery drain, complexity, and costs, because to constantly generate a bunch of additional bytes on clients that are stored alongside the indexed data is no 'free puppy'

I’m not recommending that method, I’m asking if anyone is working on blind indexes that you know of? Is the general consensus that it’s too much of drain on resources to even fool with?

I was saying the whole time, show me the JSON Schema public vocabularies so I can look them over. I’ve already accepted that some people are going to use JSON Schema and some JSON-LD, I have read the W3C recommendation w3.org/TR/json-ld11/ JSON Schema has not been on my radar.

Even in the post you linked to what I'm saying is apparent: you need to generate an explosion of duplicate data on the client for every state change to keep indexes current, and it balloons the toll against a user's alloted storage capacity in free hosted storage scenarios.

I honestly don't think the perf, client requirements, & UX implications make such complexity viable at scale for diverse, multi-writer, eventually consistent scenarios. We took a simpler path w/ DWNs and don't include encrypted data search for this reason, but could add it later

Wait a sec: why have you not read the spec that is at the core of this whole conversation and all the GitHub issues we've discussed/referenced throughout? I think it's fair to say Gabe may have assumed you had read the VC spec and knew of these core features we're discussing, no?

Why do you assume we don't know LD? I've worked w/ LD for many years. For ION we even used advanced LD mechanisms, like @-base, to enable relative refs in DID Docs - it was ironic b/c we used an LD feature the LD crowd then bitched about endlessly, as if its own features was bad.

Your proposal is forcing JOSE and centralized registries on us... Celebrate diversity ... Not everything has to be the same... JOSE and COSE don't require context and they are doing just fine... Stop arguing for monoculture?

If you look at the smart health card mapping, it's pretty good... But the fact that you have to transform to make the data model compliant is proof it's not without transformation.

As the title suggests, it's about a breaking change proposal from a group of people who want to rebrand what W3C Verifiable Credentials are... To make them exactly JOSE and COSE.... And I've yet to hear any answers for why not use JOSE or COSE other than a marketing one.

You should consider using JOSE, COSE, or PGP all of which don't have a semantic requirement... Why is it a good idea to make everything the same again? Isn't that like saying diversity is a bad thing?... because it's different?

This is like saying that alg in JWS is being forced on you, because you have to register algs for interop.

Maybe at DIF... But W3C isn't even allowed to refer to it normatively, because that would be a downref.

@csuwildcat @OR13b @decentralgabe Do y’all know any projects focusing on Encrypted Searchable Indexes like this paragonie.com/blog/2017/05/b… I know Fission is.

Yes, @decentralgabe I see you worked on this, why didn’t you just share it versus going through the JSON Schema vs JSON-LD debate? Geez 🤦🏻‍♂️

Is this what you’re looking for? w3c-ccg.github.io/vc-json-schema…

You don’t just go change an entire spec like that, you are going to have a hard time convincing some goats that have been working on this for years. I feel you though, @OR13b is working on some suggestions that might work. Where are the JSON Schema versions of the spec?

@davidstrayhorn Bingo, more tools are being created for mapping and interoperability now semantifyit.github.io/RocketRML/ and github.com/jiaoxlong/jsc-…

There needs to be more work done in encrypted data in the UX that is verified by a private key, blind indexes, ACL, encryption at rest along with libP2P for true privacy. medium.com/@joshuakelly/b…

I’ve been trying to figure out whether various individuals’ preferences wrt all the various data models (JSON Schema, JSON-LD, JOSE, RDF, etc) are mostly matters of taste and familiarity or whether there are deeper but elusive principles involved that I’m missing.

There is nothing wrong with JSON Schema, its perfectly fine, it just another data format. Some people like the JSON-LD formant because of the linkage to RDF and apparently only nerds like it based of @decentralgabe and @csuwildcat 😂 I have news for you we are all nerds here.

JSON schema are pretty integral to what I’m working on but whether that means I’m big brain or small brain I have no idea 😜😂

@decentralgabe Are there published JSON Schema versions of Verifiable Credentials? I have been looking for it but don’t know where to look? All I know is it should be referenced with $something or another.

@decentralgabe I do see it in the Turtle version w3.org/2018/credentia…

I will start paying more attention to JSON Schema, will you do the same with JSON-LD?

JSON Schema has been supported in VCs for years. Check the “credentialSchema” property

@csuwildcat I was not planning on learning JSON Schema but chose to do so because it is the choice of BlueSky and TBD I’m on board with working together. I’m just bitter because I am ready to build something cool vs the dang standards changing overnight.

@csuwildcat It would be very helpful to have more examples with JSON-LD working with JSON Schema the powers that come with both formats United and tooling to convert depending on what your tech stack of choice is I have put a ton of research in docs.google.com/document/d/17n…

😂

It’s a matter of using the right tool for the job, it’s ok to not understand it. It’s only semantic syntactical sugar on top of JSON-LD once you take the time to learn it like I am going to do the same with JSON Schema, you will see the benefits.

Great, so now that we agree that the JSON Schema and LD schematic layers are no more/less decentralized, what even is the debate? Why don't we just make it so you can use any schematic mechanism you want with a signature over it and call that Verifiable Credentials?

@csuwildcat I agree with you on DNS let’s quit going back and forth on the Schema format.

twitter.com/decentralgabe/…

@csuwildcat @decentralgabe Let’s agree to work together and not against one another, I’m sure you have many man hours learning JSON Schema as we do learning JSON-LD, ShEx, SHACL, ShapeTrees.org I’m willing to learn your methods let’s quite this back and forth.

The greatest trick the Large Devil ever pulled was convincing people @-contexts pointing to DNS domains are more decentralized than $-refs pointing to the same domains. JSON-LD and JSON Schema are both just neutral data models that can be used in centralized or decentralized ways

Is joining the W3C, participating in standards work, and putting out open source software not “working with you”? Or would you rather us adopt all your positions and call it compromise?

I told you and @decentralgabe I will learn JSON Schema only because we have common goals. If you would work with us things can run smoother.

No

Isn’t JSON Schema being forced on us?

They can be moved to CIDs there is already a group working on that bafkreiet2uvruwbey7owkbgkphaweboaw5akbotiw6qusutyb5jfmemgui

You are quite literally forcing context on us. Any other claim is a plain lie

Surely you realize you can have N different JSON Schema docs written by N different people with their refs encoded as IPFS content addresses and they would compose without any centralization or technical coordination, besides simply knowing an address? LD is no more decentralized

I definitely have something against folks claiming LD is somehow magically 'decentralized', because that's straight up false. It's no more decentralized than a JSON Schema doc served over IPFS.

What you just linked to is a centralized domain, on centralized DNS. You're likely pointing to a *federation* of known domains pointing to each other's URIs. I think you may be using 'decentralized' here in a way most people would find to be inaccurate.

@decentralgabe @csuwildcat What do you have against the JSON-LD community we are working hard to make tools to adapt. I have not see much effort in your actions to be helpful. No one is forcing context on you we are trying to adapt.

Where are the open ones like lov.linkeddata.es/dataset/lov/ I will be more than happy to learn them.

Sure you have: you make up a schema that defines shape/values, publish it in the open (whether you do it with others or not), and serve it from a decentralized URI scheme/layer. Boom, decentralized schemas resolvable over decentralized protocols, 0 rocket science involved.

Seems like the key requirement is: ‘Source of truth you can rely on and understand.’

I haven’t seen any open vocabularies for JSON Schemas, where are they?

This notion that using a JSON Schema doc/URI to indicate the contents of credential data = "closed"/"proprietary" is not only fallacious, but downright bizarre. Can you substantiate your claim here, because JSON Schema itself isn't centralized, and a URI on IPFS isn't centralized

I gotta agree with Gabe, while LD is useful, it’s confusing for new people coming into the space. I didn’t actually know what “@context” did for months. It should be optional for use with extensions such as the traceability vocab

Good I will learn your tools, teach us how to utilize your projects vs trying to change our specs we have been working on for years.

In fact I am the one creating those tools. I think I get it, but thanks for checking.

@decentralgabe Are you not understanding, you need semantics to understand what you are verifying in open vocabulary? If you want to verify closed proprietary schemas there are other tools for that. Look at the tools that TBD is creating for JSON Schema verifications.

My take: Standardize: 1. How to serialize. 2. How to sign. Semantics: 3. Whatever each community wants.

Credentials are bigger than a “JSON” or “LD” thing

I have been following it, what you will see happen is that @ context is part of the web that will be important to the semantics of the spec

It is the spec I suggest you use JSON Schema in other scenarios that can accomplish your goals vs trying to change the Linked Data community. No one is going to JSON Schema projects and saying kill the squid 🦑

“Always will be” - no this is why there’s a working group and a v2. 🤦🏻

You do realize that context has always been the standard and always will be, there are other tools that do what you are interested in.

Maybe you should read the discussion first then get back to me

Sure, there are a number of different uses. First is for the data models themselves, to validate whether a piece of data is compliant with a data model or protocol. The next is credentials. You define a schema that defines the terms in a doc, relying on it as a source of truth

Context is important, I hope that you understand that.

If it doesn’t, JSON-LD is in fact forced upon everyone

Hopefully that does not happen

Would you mind communicating more about JSON Schema, I am going to learn it because it’s coming up a lot in TBD and BlueSky

Ha! Forcing is exactly what’s happening in the W3C Credentials group. github.com/w3c/vc-data-mo…

I don’t think anyone is forcing semantic interoperability on anyone. I sometimes feel the same way about JSON Schema only because I want to interop with you no matter what your schema requirements are. semantifyit.github.io/RocketRML/ github.com/transmute-indu…

All well and good. There are many data formats, protocols, religions, flavors of ice cream, days of the week, operating systems, types of paper, and beverage varieties. I don’t think we should force our favorites on everyone else. That’s what decentralization is all about.

You mean JSON-LD and the wide pools of Linked Open Vocabularies lov.linkeddata.es/dataset/lov/? I prefer open source just like I prefer open well known vocabularies that are already established and have been broadly adapted already. Welcome to decentralize open web that already existed.

sure, but also used to define a shared vocabulary

@decentralgabe Isn’t JSON Schema for compliance constraints?

JSON-LD

@decentralgabe In the context of?

Complying with something without deriving any value from it is the definition of bureaucracy & uselessness

@vitorpamplona You should check out the work being done at the Solid Interoperability Panel, ShEx and SHACL and ShapeTrees.org one main goal is Healthcare Interoperability 👇👇 janeirodigital.com/blog/the-decen…

FHIR has its own RDF support. build.fhir.org/rdf.html Lots of people tried to create JSON-LD contexts for FHIR, but I have yet to see a reliable/complete implementation.

This is why we have been pushing people to learn JSON-LD vs JSON Schema, there is nothing wrong with JSON Schema for validating data for a proprietary Schema but when it comes to interoperability JSON-LD is built on RDF which not complicated if you take the time to learn it.

That being said, SHCs in health care work great exactly because they can take in any FHIR payload and sign. There is no need to semantically stamp it with a context at the root node - verifiers figure the semantics out later.

The worst part of Smart Health Cards' spec is that it doesn't fit into the FHIR stack and it also doesn't fit into the Verifiable Credential stack (no DIDs). I understand that FHIR is a semantic spec and thus LD is somewhat duplicated attrs, but an LD-Proof would have been better

If you are just working on credentials for English speaking people. JSON-LD gives you the ability to really be international and readable globally. Semantics and other languages matter.

Agreed, they don't rely on it, but they comply with it. Unlike using the DEF header on a JWT payload... Which afaik was invented by smart health cards and isn't documented in any RFCs. But I sure wish it was, because compression is really useful... especially when not using COSE.