Hi there. I am not sure if I have placed this question in the correct category but here goes.
When first looking at Solid I thought I read somewhere that the Pod Servers’ WebID structure could be either as a sub-folder after the domain TLD or as a sub-domain as in:
I realise that the settings on the server in both instances would have to be different to handle the folder naming and ordering conventions, Is this possible? as I can’t find reference to it now, and is there a thread I haven’t managed to find?
The username you used to create the sub domain is simply that, it is your account username. Your WebID is who you say you are on the /profile/card#me page of the site/pod.
@adventure - thank you for correcting my syntax - yes I made a mistake in how I wrote it. You have identified that I really meant username.
From my understanding of re-reading WebID standards and the URI structures. It is possible to consider the example of a realistic WebID being for example "apodserver.com/username/profile/card#me or maybe due to a server identifying the username as LinkedIn do by inserting a subfolder before username. (~/in/username in LinkedIn’s case) but ~/p/ or anything might work I suppose.
I was enquiring if this URL format has had any work on it connected to the community Node Pod Server ?
I believe there have been some conversations about that but, not sure that it gained any traction, IMHO, nor should it. What would be the benefit to doing that? do you have any examples of why that may be bettor then the way things are now? Can you explain how that would be to the advantage of the user, and not the pod provider?
If you put a username under a sub folder, then you give a type of control to the owner of the pod server to possibly manipulate certain portions of the users data.
Pod providers will I expect follow the convention you gave or something along those lines, but that’s just a convenience and not a great form of WebID.
The problem is that you don’t own your own identity. In this respect it is much better to have a WebID based on a domain you own, in which case you can have any form you like, such as https://webid.martinsandone.com although having a fragment is preferred (adding #me or something else like that to the end). You could then have that redirect rather than running your own pod server, although I think the pod provider would have to explicitly cater for it.
There are no restrictions on the form of a webid so long as it is an absolute URI. What matters is that you control the content which is returned, and that this conforms to the WebID spec. It’s best to have a fragment though, because otherwise you need it to redirect to a URI with a fragment and that’s clumsy and I think error prone.
Thank you @happybeing for confirming my similar thoughts.
Whilst I agree that having our own domains enables us to “feel” more secure in controlling our WebID’s - in truth we are renting the domain like a mail box. If we forget to pay the domain registrar at any time - there is a very high likelihood that our domain (and WebID ) is gone.
I am very interested in any concept that means our WebIDs are really in a format that we truly own.
Sub domain web IDs are no safer from the main domain owners than a sub-folder format.
I agree that owning your own domain is not ideal either for the reasons you mention.
It is much better than a subdomain on somebody else’s server, particularly with Solid, because migration is made very difficult without the cooperation of the pod provider, and as it is not in their interests to help people leave this could be a problem at some point (cf. bait and switch).
However, I hope there will be better solutions to this. This may be one of the things which DID could help with, although I might be wrong because I haven’t followed the discussions about using DID with Solid.
My own solution to this and other issues with ‘pods as a service’ and indeed using servers at all, is to put Solid on SAFE Network. On SAFE your public name is secure, is entirely under your control (no intermediary), human readable, and never expires (no renewal fees).
I’ve built various demos of Solid apps running on SAFE including showing use of Solid apps working with a SAFE WebID. The demos are no longer live pending release of SAFE Fleming (an almost complete release of the network, for testing) but there are videos that show how various parts of this work, and there are other apps that can be tried out using SAFE IDs to check out the UI which is very nice because creation and selection of public names (IDs/domains) and websites are all integrated in the SAFE Browser.
I post updates about putting Solid on SAFE in the topic below. I’ve paused atm awaiting SAFE Fleming, to play with other things but will get back to this in the new year.
@happybeing Thanks for the explanation and intro to SAFE. I am looking at scenarios where a lot of the time users could be offline without consistent access to the internet - so I will keep an eye on SAFE to see how that framework handles such things.
I don’t see an issue wrt SAFE, is the same for server: ‘offline first’ is a thing with SAFE as much as Solid pods or any web app. Before putting Solid apps on SAFE I demo’ed exactly this using RemoteStorage.io which is similar to Solid but supports offline first operation as standard.
