WebID/Public ID confusion

[Sascha]

I’ve been messing around with different versions of the Safe browser and some apps for some time and don’t really remember what I’ve done. I never got the difference between “WebID” and “Public ID” and I still don’t. I had a little page up at safe://nature.sascha/Skogsmard.html, but that seems to have turned into trash at some point. I only see jibberish at that URL now. As I recall that page was supposed to be about tanning skin the old way. It contained a bit of text and a picture or two.

Anyway, I’d like to use the WebID/public ID “sascha”, but that seems to be taken already. I believe it’s been taken by myself and something has gone wrong. I’m attaching a screenshot. Please advise.

[bochaco]

Hi @sascha, can you please confirm which versions of the SAFE Browser and WHM are you using there? you should be using the latest ones: New Peruse & Web Hosting Manager

What you are seeing there at the URL is not trash but the content of your WebID safe://nature.sascha.

It seems you created a WebID on a public name you’ve used before for uploading a website with WHM?, but I’m not fully sure that’s actually possible, as the WebID Mgr. app wouldn’t have access to overwrite it (asking for such a permission wasn’t implemented yet), so I’m confused, please confirm the version so we can try to reproduce it.

[Sascha]

I got these two today:
https://github.com/maidsafe/safe_browser/releases/download/peruse-browser-0.7.0/Peruse-v0.7.0-linux-x64.zip
and
https://github.com/maidsafe/safe-web-hosting-manager-electron/releases/download/0.5.0/web-hosting-manager-v0.5.0-linux-x64.zip

[bochaco]

I will give it a try tomorrow and explain what’s happening and I will also try to describe the concepts of webid, public id/name, as that’s something I actually wanted to start doing, i.e. create a list of concepts and the names we use for them towards having a common language moving forward. From looking at other projects they have this and I think we are lacking such a thing.

[Sascha]

Here are more screenshots of my problems.
My WebID seems to be “sascha”. But when starting Peruse from the command line I get the message ‘Requested public name is not found’, among some other messages that I don’t understand. As can be seen in one of the screenshots, I get the same message when trying to open safe://nature.sascha.test.html in the Peruse browser.
When going to safe://nature.sascha I get some code but no “website”, and the “loading circle” for that tab won’t stop spinning.

Here are the terms/concepts that I personally don’t really understand yet:
Web ID
Public name
Public ID
It may just require more reading on my part, but the spelling of these should be standardized anyway, so e.g. “Web ID” is always written either with or without a whitespace.

[happybeing]

WebID is the correct form according to the w3c spec.

Public ID and Public Name are both used to refer to the same thing, which is in part the SAFE version of a clearnet ‘domain name’, but also used as a personal identifier on the SAFE Network.

At this time only the Public Name/Public ID is part of the official SAFE API. Support for a SAFE WebID is experimental but I think likely to become part of the official API at some point and in some form.

What are they?!

Here’s my understanding, which may need improving

Clearnet

The function of a domain on the clearnet (as an address for Internet services such as a website) is different to a WebID (which is an identifier for individuals or groups, such as an organisation), and can be used by those entities to verify themselves, establishing the right to access data or services. So a clearnet WebID is a kind of universal login, with some extra capabilities built in, such as additional information about the owner entitiy(s) (eg like a public profile).

SAFE

On SAFE, a Public Name (aka Public ID) handles both functions: it is an address for services such as a website, and an identifier which can be used to establish rights of access to data and services (ie by being logged into the account which owns that Public Name). So it covers much of what both a WebID and domain do on the clearnet, but without the extras such as a public profile. Those extras could have been added in a SAFE only way, but by adopting the form of a WebID we get the extras, plus quite a bag of bonuses.

A SAFE WebID establishes compatibility with a powerful feature that has the support of Tim Berners-Lee and others, and brings with it an ecosystem of applications, tools, and data (ie Solid, the Semantic Web/Linked Data, SPARQL queries etc) that can change the way everyone relates to information, applications and services, in ways that will add enormous value to the SAFE Network.

For anyone who wants to learn more about that value, may I recommend my presentation to the SAFE DevCon in April 2018:

DevCon talk Supercharging the SAFE Network with Project Solid

DevCon talk “Supercharging the SAFE Network with Project Solid” by @happybeing Watch the video with introduction by @joshuef (thanks Josh) here (this link is for the whole DevCon but will start at my talk): [SAFE DevCon 2018] Ask any questions on this topic and I’ll do my best to answer ASAP. Here’s a link to the slides I showed, but also quite a few more which give more about Project Solid as well going through what was presented in the video: FYI the Links from the final…

[bochaco]

@Sascha

I had a little page up at safe://nature.sascha/Skogsmard.html

This is what was really confusing me, but am I right @Sascha that such a Skogsmard.html webpage was published before the alpha2 data reset a couple of weeks ago? is that what you meant when you said you had such a webpage? otherwise, it doesn’t make any sense to me as I don’t see any old entry in that public name (‘sascha’) that would have linked to such a file.

The public name ‘sascha1’, and both subdomains ‘nature’ and ‘test’ are correctly published, and I can see the websites published there without isues, i.e. safe://nature.sascha1 and safe://test.sascha, so that’s fine.

@Sascha

I’d like to use the WebID/public ID “sascha”, but that seems to be taken already. I believe it’s been taken by myself and something has gone wrong

This is just as I mentioned before, when you created your WebID with the “WebID Manager” web application, that’s when the public name ‘sascha’ was taken (by you) to publish your WebID profile document. This is because you entered nature.sascha in the “WebID URI” field, as you can see in the “WebID Profile Manager” screenshot you shared.

This application registered the public name sascha and published your WebID profile at the subdomain nature, and when you enter the complete WebID URL in the browser it fetches it, and it renders it using one of the standard serialisation formats (Turtle format) for WebIDs, as per the specification we are following: WebID 1.0

So, here everything is as expected, you published your WebID profile at safe://nature.sascha1 and when you query that URL with the browser you get the raw content of the profile in Turtle format (the WebID Manager webapp renders this content in a nicer way as you can see).

Now, the Web Hosting Manager won’t show you the public name sascha for you to publish a website on it because we still didn’t make the WHM app compatible with the data format (RDF) used by the WebID Manager app, so eventually you will be able to publish a website on the same public name where you published a WebID but not just yet as we didn’t have the chance to implement it, that’s it.

@Sascha

when trying to open safe://nature.sascha.test.html

This is the incorrect path to your webpages, the websites you uploaded with the WHM are at safe://test.sascha1 and safe://nature.sascha1

@Sascha

When going to safe://nature.sascha I get some code but no “website”, and the “loading circle” for that tab won’t stop spinning.

As I explained what you get is the content of you WebID profile since that’s all you have published at that URL, the other websites are at the other URLs I mentioned above.
The issue with the loading indicator is a known issue which has already been solved and it will be fixed in next version of SAFE Browser to be released. You can see more info about it here and here.

As per the these concepts of Public Name and WebID, considering what @happybeing already explained, what you basically did was the following:

• You used the “WebID Manager” web application to generate a WebID profile document, i.e. a document which contains your name, nickname, picture/avatar, etc.
• When you submitted that with the “WebID Manager” app, it stored the profile document on the network and published it at the Public Name sascha, under the subdomain nature, therefore it can be fetched using the human readable URL safe://nature.sascha

I hope all this starts making sense to you

[happybeing]

This raises a question or several [edit: it now appears!] Gabriel.

Does this mean that the current implementation can lead to a WebID that serves as a replacement for the current features of Public Name (ie a superset of the capabilities of a Public Name)?

And if so, will one be able to use all features at once or will there be a need to choose, for example between a website or a WebID profile. Some examples of URIs for both on the same ‘id’ would help me here, to show the possible combinations, any restrictions etc.

I’ve been wondering why WebID wasn’t implemented as a SAFE service (like www) so can you comment on that too?

And if the choices made for WebID might feed into changes to the way anything else (such as SAFE services are implemented)?

I realise it’s all a bit fluid but would like to understand your thinking. It will also help me decide when and how to support WebID on SAFE Drive. Any thoughts on that welcome too, but happy for it to be ‘my problem’

Seeing the confusion this is creating, for me included, I wonder if having WebID as a SAFE service might be a better UX.

[dirvine]

@happybeing

Seeing the confusion this is creating, for me included, I wonder if having WebID as a SAFE service might be a better UX.

I think so, as I was reading this thread it did occur to me that we have not made webid and RDF, in general, a first-class citizen. I was considering that we should do an RFC here ( @bochaco @joshuef ) that covers what an account actually is (a blob of data including keypairs (which the public key is an id), root directories etc.) and how the network deals with wallet addresses (public signing key) etc. and how all this links with webid’s. To me, that would clear up the current situation, where there is confusion and a feeling of heath Robinson approaches.

The whole account creation, that can include creating id’s or adding an existing id as well as how an id can be funded with a safecoin and added when creating an account (to prevent account spam) all should feature in this RFC as well as how to create all of this against the API. Also though having webid as a primary and default service in the dns attributes would seem to make perfect sense.

I should explain the id creation here. So I have an account, I add an id (wallet address), put a safecoin in that and give the id to somebody. They then take the id (however I give it to them, email, on paper, over the phone etc.) and when adding their account, type in that id (which gives them also the private key) and the network takes the account create RPC, checks for the safecoin, adds the account and adds the safecoin to the clients balance (in a new id they create).

That kills account spam and will make giving a safecoin quite simple.

Also if a person runs a vault and it farms a safecoin, they can take the ID the vault uses to get safecoin and add that to their account as well. So getting safecoin from a vault to the client account is also simple.

Then we have fully paid accounts from step 1. all we need to is conjure up ways to give those id’s (keypairs) to people to create accounts with and I think there is a multitude of ways to do that.

[happybeing]

This nerd and I think many other here would love that RFC (sorry guys ).

[joshuef]

I’ve been working towards some RFCs that would elucidate some of this, so hopefully I can get that tidied up and out to folk asap.

Though to clarify in general: One part is the DNS and what a WebID does in that.

To that, I’d say the basic premise (for me) is that a webId is just some data with entries about a user. It can be wallet addresses, websites. Whatever. So you can give someone a webId, and, depending on the app, it can choose what info it wants to use.

If for example, I gave you safe://josh and I have a website in there… And you access it via the browser, the browser could resolve to this website data (if it was set to look for a website automatically). Which I think is what you’re touching on @happybeing.

The other way beyond resolving automatically, could en up looking like safe://josh#somewebsite where somewebsite is a graph entry pointing to an NFS or DNS mutable data, which could also be resolved.

But there’s no guarantee that a webId would have a website. So in this sense a webId wouldn’t replace the DNS system… and would be more about an application interpreting data therein.

---

As for making RDF a first class citizen, I think we’re making in roads to do that (again… I’ve another RFC to finish tidying). I do think we need to make RDF as simple as possible for developers to grasp and save to the network (and to dogfood that and be using it for our apps).

And while I think we (maidsafe), should be leveraging WebID in some form for apps (as @dirvine notes with wallets, and as we’ve shown with patter), I think that’s more of an app level setup (that we facilitate this wallet/Id integration), than so much as it needing any network support (beyond RDF helpers).

---

@happybeing

I’ve been wondering why WebID wasn’t implemented as a SAFE service (like www) so can you comment on that too?

Essentially a WebId is just data. It’s another document. And how things interact with this is where utility comes from. So there’s no real need to specify a specific type of subdomain or service for it. You should be able to make a webId and have it live only at the xor address. Or you can specify something in the publicName system if you want. As it’s just data, you have the flexibility to do what makes sense for you.

[happybeing]

@joshuef

Essentially a WebId is just data. It’s another document. And how things interact with this is where utility comes from. So there’s no real need to specify a specific type of subdomain or service for it.

The same is true for a website, and this doesn’t address the question of UX and the confusion we have presently. I can think of technical reasons for not implementing it as a service (e.g. indirection), but am wondering if it makes it easier for users and devs to do so. Perhaps we can allow both? I.e. you can create a WebID as a service, or just a file at an xor address for ‘expert’ users/devs and special cases. But let’s wait for the RFCs

EDIT:

@joshuef

Essentially a WebId is just data. It’s another document. And how things interact with this is where utility comes from. So there’s no real need to specify a specific type of subdomain or service for it.

I think this isn’t quite true! A WebID is a URI with a fragment, not the document. So it is an identifier first and foremost, and is more useful it if resolves to an RDF graph within a document, but is never a document - because the URI of a document identifies the document and not any other kind of entity. So a WebID must always include a fragment.

[joshuef]

@happybeing

Perhaps we can allow both?

Indeed. That’s what I’m saying above.

“you have the flexibility to do what makes sense for you.”

As for the confusion… I think this has partly arisen as the POC sets up a publicName to display your WebId. This is due to the fact that we didn’t have a content addressable xorname url system, and we needed to make a publicName so they could be accessed/shared. But that is not needed for webIds as a document.

Another part of the confusion may well be the naming of these systems. publicName, WebId are similar sounding when you’re not familiar with the details. And so I’d wager that we need to look at the naming of these things to some degree as we go forth.

Equally, some time spent in the UX mines should help clarify differences / user creation flows (as opposed to us dev types throwing together something that works).

---

@happybeing

I think this isn’t quite true! A WebID is a URI with a fragment, not the document. So it is an identifier first and foremost, and is more useful it if resolves to an RDF graph within a document, but is never a document - because the URI of a document identifies the document and not any other kind of entity. So a WebID must always include a fragment.

And now we’re diving into the semantics of WebId… But if we’re looking at how things are resolved. WebId Profile document vs the ID itself. We can amend the above to suit the ID vs the document thus: safe://josh#me/somewebsite.

Which as a subgraph of the webId… Could still be resolved in the same fashion as above.

---

Now… would you put your wallet address/website in the profile document or the WebId portion of that document? I’m not sure what’s best there. What are the pros/cons are there.

---

And while we’re touching on the webID url / fragment malarky. It’s worth considering how confusing that is. And if we need that one SAFE vs something adaptation of a webId system. Right now we’ve been rolling with the WebId standard. But do we need to? Should we be? Is the confusion of the fragment idea worth keeping? Is there another way of doing that? I think that’s all stuff that’s worth looking at (though that’s for another thread/RFC )

[Sascha]

@bochaco

Skogsmard.html webpage was published before the alpha2 data reset a couple of weeks ago?

That’s right. I just thought some of that data was preserved. No matter. I’m just testing and trying to understand stuff.

I’ll be putting up a real site about real country living when SAFE is more stable. No keeping animals suffering in small cages, and no silly plastic wrapped hipster “health” food for me.

[joshuef]

@happybeing ups, forgot to ask in the above: Can you clarify for me what you see as the benefits of a webid as a service / how that might work, as it’s not entirely clear to me what you’re imagining…

[happybeing]

@joshuef

Can you clarify for me what you see as the benefits of a webid as a service / how that might work, as it’s not entirely clear to me what you’re imagining…

Nor me

SAFE services themselves are still not clear to me, so I hope there will be an RFC expanding on potential use cases. I’ve been developing my own approach, but don’t know if it fits the ‘vision’ because that isn’t well defined.

So my answer, while it must be vague is that its a simpler UX to present to users along the lines of:

• create a public name and then you can do stuff like, hang a website on it, your email, a WebID, a Solid/LDP store etc.

Versus:

• create a public name and hang any of those things on it
• except for a WebID enter some profile information which creates a document that you probably think is a WebID but isn’t, and as a side effect we create a Public Name (or assign it to one).

I still find the second confusing and I’m supposed to get this stuff. How you implement it as a service is different, but the UX might be…

• Click Create new WebID
• Select or create a Public Name to use
• Configure the WebID (ie URI) and optionally enter profile information
• Click Save or Cancel

The ‘Configure’ step would be a form which requires you to specify the URI for the WebID which will constrain you to ensure it is valid (ie has a fragment) while offering defaults and sensible options.

Options such as:

• #me, #it or your own text, for the fragment
• webid.publicname, anythingyoulike.publicname, or just publicname for the profile document address. The last one clashes with www so maybe that’s ruled out, but I hope that clarifies.

@joshuef

And while we’re touching on the webID url / fragment malarky. It’s worth considering how confusing that is. And if we need that one SAFE vs something adaptation of a webId system. Right now we’ve been rolling with the WebId standard. But do we need to? Should we be? Is the confusion of the fragment idea worth keeping? Is there another way of doing that? I think that’s all stuff that’s worth looking at (though that’s for another thread/RFC )

Well this is a discussion we should have on the Solid chat. I believe there are sound technical reasons which Tim has explained there from time to time, so any counter proposals should be exposed to their feedback.

But regardless, I don’t think we can call it a WebID unless we follow the spec. That would I think prevent us from leveraging Tim’s work or getting people working in that area on board with SAFE.

[bochaco]

Adding some comments from my side, but I think @joshuef has covered everything already

@happybeing

I’ve been wondering why WebID wasn’t implemented as a SAFE service (like www) so can you comment on that too?

They are indeed a service like www or any other subdomain you publish in a public name. So regardless the way an app can allow you to do all this, this is what it really happens underneath at the data representation level:

• You have a Public Name, this is just a way to be able to reference and find a piece of data on the network using a human readable name, human readable name which you then see in a URL. The Public Name is simply the hash of a XOR address.
• What we store at the location of a Public Name it’s a container, the Public Name Container (we are trying to use RDF for the format of such a container), this container lists services, each of these services is assigned a name and mapped to the location where the service’s data is stored. Here, again, a service name is just so we can have a human readable way of referencing and linking a service. So the service name becomes the subdomain of the URL, e.g. if you add to your sascha public name container an entry for a service called nature, which is mapped to a location where all the website’s files are stored, you can then be able to find such a location for the website’s files with safe://nature.sascha.
• A WebID Profile document (if we want to start being strict with names) is just a document, a file, like any other file you can store on the network. When you create a WebID Profile what you do is store a WebID Profile document at a random location, just like when you store files of a website at random locations on the network (it depends how you decide to store these documents they may not be really random locations, but let’s forget that for now). After you stored the WebID Profile document at a location on the network, you can opt for publishing it with a human readable URL by linking it from a public name and service name. E.g. if you decide to do so by publishing it at safe://mywebid.josh, you add an entry to the josh public name container, this entry has a mapping from service name mywebid to the location of the WebID Profile document. A WebID, strictly to what the spec states, will then have the # with any of the subgrapth you stored in the WebID Pofile document, e.g. safe://mywebid.josh#me.

Thus, since everything is a service, which is stored anywhere on the network, you can then decide to reference/link to them using human readable URLs, or you can use the content addressable system we are working on and reference to it with a simply XOR URL, so I could effectively have a WebID which is something like safe://hyfktcegr68th4og68y9eks99cie14qtw44zpmjdttqqujxr3bb5jnnip7r:16048#me

[Sascha]

So now I have two identical WebIDs (URIs, not the documents signified by them)?? I’m really confused. Could be I’m just being stupid. In that case, sorry.

[bochaco]

You now have two WebID Profile documents, each stored at different random locations, both published with the same sascha public name but different service names, nature and webid.
So it’s like publishing two different websites on a domain you own but at different subdomains, the only difference is that you are publishing WebIDs Profile documents instead of websites here.

[happybeing]

I think it would be clearer if the terminology in the UI was accurate and precise.

It isn’t showing any WebIDs (no fragment) so it’s not clear whether it is listing profiles, ids or both.

EDIT: it also uses WebId rather than WebID.