Any plans to make WebIDs independent of service providers / prevent vendor domain lockin?


#1

@Daniel-Albrecht wrote:

As it is now, WebIDs are always URLs. While people like me have own domains, unfortunately, most of people don’t. They will get a WebID from an existing provider, but then they’re locked in to that provider, because switching it means switching the WebID. It’s like with email addresses, nobody wants to change them, because they would have to tell everyone.

Are there any plans for distributed WebIDs, over which no single entity has control? And if so, how could this look like?

I’m asking mostly out of curiosity, because I think solid and its decentralization of data storage for user data is an important step forward in combating online provider lock-in, but I likely won’t have time to contribute much. But I can give some ideas.

I think the biggest challenge for creating distributed WebIDs would be to make it usable with current browser accessible technologies. I see 2 possible solutions to this:

  • One is to extend the DNS infrastructure. There are two variations of that possibility:
    • If some of the well known existing internet authorities such as icann would provide free domains on a new TLD for people only, with an API to register them automatically, it would allow everyone to get their own domain without any effort. But it would place control over the domains in the hands of said authorities, which may not necessarily be much better.
    • If we do the same as above, but instead of letting the authorities maintain the records for said TLDs themselves, the DNS servers are instances of a blockchain client, like with namecoin, then not only would nobody be in control of the domains, if the authorities choose to stop the service, the browsers could use their own namecoin or similar instances to resolve the domains instead. The problem in that case is that blockchains usually need blocks to have value to keep miners and stay secure, which means domains have a cost and thus the same problem regular domains have regarding accessibility, and blockchains like namecoin don’t save domains forever, in addition to taking a lot of space.In addition to the problems of both approaches, I doubt that icann and co. would be interested in providing such a free service.
  • A URN could be used for WebIDs, which are resolved using trackers, similar to how WebTorrents and magnet URIs work. The main issue with this approach is to find a way to not relay on a fixed set of trackers, to check that they are synced, automatically update the used trackers, keep track of which ones are not malicious, and validate that the WebID information are correct (using a hash as webid wouldn’t be user friendly, so the webtorrent approach to this wouldn’t work.). I believe this to be solvable problems, but very difficult ones.

A combination of the above could also be possible.

Of course, it could be way easier to create standards for protocols which can handle the lookup of URLs based on an URN without needing any hashs but just a resource name/type without a central registry/authority, and if browsers would then implement those, but I don’t know how something like that would look like or if there are any.

What do you all think, where and how could or should this be solved? Is this even the right place to resolve the problem, or should it be discussed/solved somewhere else?

There has been some discussion on https://github.com/solid/solid/issues/195 with @RubenVerborgh, @melvincarvalho, @Kjetilk, and @elf-pavlik and would like to invite more here.


"move it at any time, without interruption of service"?
#2

There are already decentralised WebIDs on the SAFE Network, you can get an idea from this brief explanation of how to create them: https://safenetforum.org/t/creating-your-webid-on-the-safe-network-alpha-2/24772

I think a (read-only) proxy can be created to support fetching WebIDs from safe:// protocol. The WebIDs from the SAFE Network can be fetched in Turtle, JSON-LD, and other formats, so from my understanding using Turtle would allow them to be compatible with Solid.