Christopher Allen: Service address stuff. What is the scope of how much we will be standardizing? What is the minimal verifiable claim Repository service? ✪
Drummond Reed: The proposals still need to be added to the spec. Action item for drummond. ✪
Proposal to solve: how do you go from did service url to a target url. ✪
Manu Sporny: We should not assume everything after the semicolon is a service description. ✪
Manu Sporny: The other question - how will we pass perimeter services? Why don't we make that the general mechanism. The thing after the separator we should make more ostensible than just services. ✪
Sam Smith: Service end point. shouldnt it just be end point? ✪
Manu Sporny: There was a specific reason for that. ✪
Christopher Allen: Why isnt this handled by the method spec? ALlow a resolver to handle some of this. ✪
Drummond Reed: Purpose of service names is to solve this problem. if you want to build a service url, there needs to be a general standard to turn the did service url to a target url. ✪
Chris Webber: There's more to services than just returning URLs ✪
Manu Sporny: Yes, the resolver doesn't touch this most of the time ✪
Chris Webber: Can't use colon.. we use colons all over the place in Veres One as other forms of delimiters [scribe assist by Manu Sporny] ✪
Chris Webber: I'm not opposed to it but I still don't understand why a colon wouldn't be used since we're using a colon for the others ✪
Manu Sporny: Ah ok [scribe assist by Chris Webber] ✪
Manu Sporny: Short answer it id not did method specific. the services we are hoping for are a common mechanism across all methods. ✪
Manu Sporny: Responding to Sam asked about service vs end point. concern if people mix vocab into methods (name, description, end point, etc) as a result there is a chance if we just end point it will get clobbered ✪
Manu Sporny: Developers can always change it in their method using JSONLD mapping ✪
Manu Sporny: Pending action item: we should claim all of the terms in schema.org ✪
Chris Webber: Comment on resolvers will do the work of transforming this into the url. ✪
Dave Longley: New option submitted. Would like to see other use cases for transforming the url. ✪
Christopher Allen: Can you add in those use cases here please? ✪
Manu Sporny: We don't say what the did-path does. ✪
Drummond Reed: Happy to go in and fix that stuff. Its all standard URI. ✪
Manu Sporny: Concern that what we are agreeing to will paint us into a corner. We need to give folks more time. ✪
Christopher Allen: Need definition of minimal viable service for this. ✪
Manu Sporny: What happens when you just want to select from a set of things. Its not a 1 to 1 mapping. Its not a service look up. ✪
Chris Webber is scribing.
Drummond Reed: This solves the problem by putting the service in the authority component ✪
Drummond Reed: I've never seen a use case for this where you need to do anything else ✪
Drummond Reed: What you're doing in discovery is going from abstract discovery to... ✪
Drummond Reed: Those mechanisms for selecting that would use a fragment on the did document itself, or a query on the did document itself ✪
Drummond Reed: Nothing prevents us from doing that ✪
Christopher Allen: Let me suggest we take this, puzzle through when you have multiple paths ✪
Christopher Allen: A service can be accessed through http/tor/etc ✪
Christopher Allen: They're equally valid but you want to prioritize one ✪
Drummond Reed: I don't think i understand, this is a url translation mechanism ✪
Christopher Allen: This is you're trying to move from something you understand to something you don't ✪
Christopher Allen: IPFS can go through a variety of mechanisms, ignoring http ✪
Christopher Allen: If I want to go through a number of centralized services that convert IPFS to HTTP, so I can use an http url, but that's lossy on decentralization compared to ipfs:// ✪
Drummond Reed: I understand, you've got multiple services you want the same url to map to ✪
Drummond Reed: I've seen that before, I'll say you can write custom code to do that ✪
Drummond Reed: If we complicate that about the simplified use case... doesn't preclude that you can do the simple standard way ✪
Christopher Allen: But then you're in the category of service type is an http service ✪
Drummond Reed: Which you could absolutely write the code for ✪
Christopher Allen: I'm maybe saying if you can spend a bit of time puzzling through resolving to two different things that give the same result in the end, maybe there's an easy way to do it, maybe it's just having serviceType through IPFS, something, a priority tag... but if you spend a bit of time puzzling through then tell me you can't do it, then I'll feel bettter ✪
Drummond Reed: We'll take it a look before, it's come up before, we'll see what we can come up with ✪
Chris Webber: Christopher gave a better example than I was going to, but it may be not incompatible syntax wise to reserve the `=` char and the `&` char... and if you don't specify a parameter it defaults to "service". [scribe assist by Dave Longley] ✪
Chris Webber: Similar to how languages have default parameters map in certain ways. I don't know this would make things better or making our lives harder with more options. [scribe assist by Dave Longley] ✪
Drummond Reed: Good suggestion, I'm the last one to argue against extensibility ✪
Manu Sporny: Why can't we just do did:example?resolve=serviceName/foo/bar/baz#frag-1 ✪
Drummond Reed: I do like that point, and the particular point of keep the simple case simple ✪
Drummond Reed: I'm opening to the idea of reserving = so that we can add parameterization later ✪
Drummond Reed: Since manu wasn't here last week, I wanted to cover these other 2 things ✪
Topic: Other DID Spec Items
Drummond Reed: We had query components, wanted to add things back in ✪
Manu Sporny: Not sure if your suggestion is to just use the query... but you'd have to encode the '/'s i think (if it was in the query) [scribe assist by Dave Longley] ✪
Manu Sporny: Why not follow a standard url component, you'd have to escape the slash, but anyway... you can't do ors I don't think ✪
Drummond Reed: Completely agree, and goal was to turn all three into PRs ✪
Drummond Reed: Let me just say we did stop on the json pointer thing, folks on last week's call understood the case but dave understood the case on it ✪
Dave Longley: I haven't had time to think further ✪
Chris Webber: I'm nervous that xpath style things like json pointers can be brittle and can lead to people having little bobby table type problems ✪
Manu Sporny: We haven't had a lot of agreement about ways to fetch things, especially because there are at least 3 valid ways we haven't agreed on ✪
Manu Sporny: We can say that if you're in json-only mode you can apply json pointter as is, in json-ld you can frame it... we can explore and if patterns emerge we can put it in ✪
Manu Sporny: That's the same issue we've had in json-ld and we haven't gotten consensus there, I think if we do the same thing we'll have that problem with path based resolution here too ✪
Sam Smith: I think if notthing prevents it a should as opposed to a MUST is fine ✪
Sam Smith: It's an important use case to access metadata ✪
Chris Webber: I'm really worried about putting this as a SHOULD -- it may not be obvious , non obvious risks. [scribe assist by Manu Sporny] ✪
Drummond Reed: We're at the end of our hour, good discussion, I'd like to go through the process ✪
Drummond Reed: Just to take a sec to discuss between now and then: RWoT, discuss having a DID day there ✪
Drummond Reed: I think our goal betwen now and then is to work on as many issues as we can, so we can have a stable of a spec with as few issues as possible ✪