Maybe I’ll let @joshuef comment more specifically on the technical compatibility with WebID etc. but from a UX point of view a can talk you though our thinking.
The idea is to be able to have a network wide ‘addressable’ identity for 1-to-1 communications, comments, safecoin transactions etc. that’s usable and understandable. Some of the advantages being:
If I own the Public Name jim anyone can message me from any app using @jim, or send me a payment, or tag me in a comment on any site, and it’ll end up in my comments feed.
The other user doesn’t have to worry about where my WebID is, or if I set one up at safe://jim#me or safe://jim/contact#me or wherever, they just drop in the @ and go from there. (It’s also a lot more commonly understood and in wide UX usage, and also let grammatically clunky than an #me fragmented address being deployed in the same way)
All I need to do if I want to, say, contact or send a payment to a site owner (even if they are anonymous to me) is @ the public name. So it’s not so much a place to display a contact card, as it is a way to start a conversation, but network wide.
In the browser, if I put an @ in front of any url, I’ll get either the full customised SafeID/WebID profile there if the URL owner has created one, or I get a card/generic type response allowing me easy access to the standard functions, such as message/pay etc.
I could also have different SafeID at different URLs e.g. @jim/sports, @jim/personal, @jim/work/design, and I could perhaps even use these as a way to organise incoming messages to different inboxes/feeds, or payments to different wallets etc.
And, BTW, this is all just ideas/proposals that are being worked through here, nothing set in stone. It’s one of the great advantages of working on these UX designs in parallel, but a few sprints ahead: we can get a feel for these things in use, and how they’ll play out for the user, before we commit to code.
I see benefits from WebID compatibility (easier cross marketing, association etc)
I think the fragment design is fundamental to LinkedData / RDF, so diverging from this creates two kinds of ID, one which fits with LD, and another which is modified for UX, which may introduce some confusion in UX.
I’m happy that you are putting UX right up there though and excited to play with this. At the same time I’d like us to thrash out the details so we understand the pros and cons of different approaches. Ideally I’d like to get input from Solid folks including Tim, Ruben Verborgh and Henry Story on any solution we want to look at seriously. I’m not sure if that is best done sooner or later.
Yeah, totally. It’s my job to advocate for the user, and often the way that is approached and communicated is though stories and pictures… so I’m glad you picked up on it!
As far as I’m aware though, even aside from this, we’ve already deviated slightly from WebID (hence SafeID) so it’s become its own thing. I’ll wait for josh to swing in here and explain the thinking there though.
Just wanted to put that screen shot here.
I am sooooooo happy with the road map.
So happy to be able to see these green ticks go up
Thank you Maidsafe.
A WebID is a URI with an HTTP or HTTPS scheme which denotes an Agent (Person, Organization, Group, Device, etc.)
So we’re already falling down at the first hurdle w/ safe:
I don’t think @ anything precludes fragments either. How we’re currently handling fetching any RDF doc should resolve fragments. so @happybeing#me could still be valid (assuming @ enforces fetching only webID content eg.
Whether or not we need to have fragments for retrieving the WebID on safe is a different question…
My thinking in general is that, since we cannot have true webIDs on SAFE. Why chain ourselves to a system designed for the clearnet? If there are strong reasons in favour of an approach then for sure it’ll make sense do something that way.
But whether that’s safe://me#card or safe://@ or just @ (as I favour), doesn’t mean that the underlying data isn’t still using the WebID schema.
Whatever we do, we’ll need some conversion for each ‘network’, so to speak. (eg, to use a safe: WebID on clearnet, you’d need to have some POD running SAFE:// and a server to handle conversion etc; to use a cleanet WebID you can set up a script to update the safe:// version whenever you update the clearnet one eg.)
I think part off the issue is continuing to conflate WebID (a URI with fragment) and WebID profile (an RDF document).
We can of course maintain compatibility with the profile ‘schema’, but if we don’t have a clean way to incorporate a SAFE ID as an identifier (which in RDF must be a URI with fragment) then it becomes difficult to refer to entities such as a person by their SAFE ID.
I am not concerned if we deviate from the spec in ways which don’t break things (eg using safe:// target than http://). If anything I think that one is a benefit rather than a downside.
And I’m all for coming up with nicer ways of doing this such as those being proposed.
TBH I think a WebID is currently clunky, geeky and unfriendly, so I favour a nicer form. At the same time I think that before we make it something that doesn’t look like a URI or which can’t be used to identify real world things in RDF we need to understand the implications and how to deal with them.
I think we can. The info at @josh could still be available at safe://josh/webid#me for example.
I’m looking at the alternate user friendly ‘link’ as being another way of accessing that same document.
This is one of my concerns. A WebID is an identifier of a thing rather than of an RDF resource, which is why it needs a fragment (the #something at the end).
A WebID profile is an RDF document that can contain info about various things, each of which is expected to be indicated by the fragment of the document URL. One profile could have data about multiple things, each indicated by a different fragment.
You can only identify real world things using a fragment, without a fragment your URL identifies a resource (eg RDF document) not one of the things the document is about.
We could handle this by imposing restrictions by convention. So Safe ID of @happy might imply a Web ID of safe://happy#me for example. Which would be used in RDF to refer to me, while @happy would be used in RDF to refer to the profile document.
Before deciding I suggest we look into the implications of doing something like this because I think it might cause problems down the road.
I’m not there expert on this though, hence I suggest we ask others for comment once we’ve come up with a proposal.
Sorry - I didn’t manage to get back to you… But I’m very glad to hear this and I think having type information which enables to drop unused version bits is an excellent idea =)
