The App Layer

haha - and with a first come first served approach it even allows one or more DNS resolver that involve 2 registers …

(assuming that the public key to a freely chosen private key of a register is its address in XOR-Space … and one can access a certain version of a key/value pair of a register …)

discovery-register - private key: e.g. derived(safenetforum) [since it’s derived directly from the name itself anybody can change it and just adding a different DNS resolution scheme with different key is trivial … since CRDTs are append only and the first version can only be written once it’s a first come first served approach]

  • key: rids_DNS_resolver → value: XOR-Address of a register that will reveal the XOR Address this name needs to be resolved to (aaaaand - since it’s static this value can be cached locally if the value has been read once)

XOR-Resolver-Register: can even handle multiple services …

  • mail: XOR-Adress-SafeMail
  • wallet: receiving address if someone sends token
  • site: website

(private key chosen by user freely and/or can be a multisig thing … can be transferred)

(… but ofc previous owner might still have access … might be avoidable by having a redirect to some other XOR-Address … in case of the name being transferred … but not having to iteratively being redirected many times would certainly be better for the user experience …)

edit: (but then again - since we would have static info here in case of transferred ownership … even a few hops would just be needed to be done once and then could be cached locally because it’s read-only info that can’t ever change …)

@dirvine maybe maidsafe could implement such a first come first serve scheme for a wallet service … and then the approach for other services would be obvious + straight forward but not implemented/provided by maidsafe … so @happybeing would have his ‘standard way’ but 1. a safe browser would ideally enable putting other resolvers first/define a hierarchy of resolvers … and 2. maidsafe would not engage in a name resolution system connected to any data except token transfer …?..

3 Likes

Interesting to hear that the thinking behind no DNS/Browser is a regulatory constraint, but personally I think it could be a restriction that is a blessing in disguise, and makes me really excited for the potential developments.

Having to completely rethink discovery/search might be what differentiates the network from the internet to the casual end user. Search in the usual way would have thrown things straight back into a centralised model, and the first thing most people think of in regard to centralisation of the internet is Google, rather than AWS.

Now I also understand better the excitement about AI - it would seem the best way to discover things would be to make connections with other user’s (personal or professional,) data, which would be very cumbersome to do for an individual, and impossible to approach anything like the functionality of the current internet. However, if each user had a personal AI assistant to manage these connections, assess their safety and keep track of the best way to traverse them, then it seems we could have some very powerful and genuinely decentralised functionality. The benefits of DNS would be fairly irrelevant to an AI, and although I share the concerns about how much trust we put in AI, in this case we would not be expecting any kind of omniscience, just an aid to navigation, which for the stated purpose would actually provide a richer and less biased/centralised experience than the current model of discovery.

Exciting times!

8 Likes

How about an alternative to a global DNS, perhaps more like your personal address books idea, but more general purpose, perhaps based on an existing format like RDF/LinkedData?

So I publish the URL of a register, or indeed part of my Safe Drive which is writeable only by me, but which you can read. At the root is an about me document which contains info about me and meaningful links to anything I want to share (bio, blog, wallet etc).

If using LinkedData we get a lot of ready made ways to describe and format standard kinds of document. For Safe we need only define how RDF is stored in this structure(a register or if it’s possible, a shared directory on your Safe Drive) which can then be referenced with a simple web like URL such as safe-rdf://<xor-address>/<rdf-document> or safe-drive://<xor-address>/<rdf-document>.

So we lose the global name space and instead each person can publish one or more locations where multiple RDF documents live, such as an ‘about me’ doc which can include contact details, public keys, blog URL etc, linking to other RDF documents and anything else.

So instead of just publishing an address book, it’s like each person publishing not just their own DNS, but any number of different kinds of thing which are readily understandable by standard software (and yes, those personal LLM whatsamabobs :roll_eyes:).

This in effect creates the semantic web on top of Safe Network, without a central DNS. That means publishing xor URLs at least to start with which will be fine for electronic sharing but not great over the phone, in person, business cards etc. Maybe we just live with that. :man_shrugging:

So to begin we would publish / share our xor address just as people (those nerdy Solid and LinkedData folks) share their Solid IDs (which are the URL of an RDF document that serves as an identity). But once you have my xor-ID in your app, you give it your own pet name and use that instead.

I think this is pretty much what you already proposed @riddim, so I’m just saying if this was done using Solid and RDF conventions, it becomes mainly a matter of specifying how the data is stored on Safe and providing libraries to read and write it. Using those libraries different apps can read and write different kinds of ‘document’ (bio, blog, wallet, address book etc all off the peg or easily designed formats) which can easily be read, displayed edited etc by other apps, many of which already exist.

This is pretty much Solid on Safe revisited without a global DNS, but I think it’s good enough because semantic links do so much of the work.

EDIT:

Ways forward

A great enabler would be a WASM library, or rather a base WASM library for the Safe Client API and another atop that to implement an LDP style (RDF) interface on top of that.

With those it would be possible to build cross platform desktop and mobile apps using a common Web UI (e.g. in SvelteKit :wink: or any other web framework) and Tauri.

It would also be pretty easy to port existing Solid and (LDP compatible) web apps to make native desktop/mobile apps for Safe Network. Much more quickly than if developers have to work directly with the Safe API and its native data structures.

  • Even if not for the above, in general it would be very desirable to have the Safe Client APIs compiled for WASM to start with and try building a Tauri demo app using those, to show how to create native, cross-platform, desktop and mobile apps for Safe Network.
  • Ditto for MaidSafe’s Safe Drive.
  • Ditto to implement and LDP style interface which would allow porting of Solid apps and building new Semantic Web apps, again using a web fratework with Tauri.

The above approach seems a good way to move forward fast in the absence of a DNS or Browser, which might arrive later but not inhibit developers in the mean time.

8 Likes

and even with the double-register first come first served approach data could be stored in a semantic manner … so we could have pet names (or how david put it “web of trust” - i really like that name … because this is really what it is … with shared petnames) or/and a global name space … the format in which the data is stored would surely benefit from the structure you suggest :face_with_monocle:

7 Likes

That’s right, so it’s impossible as is to target a register to an address. Right now all the API is in github

5 Likes

Not being able to target where data will end up feels way better tbh :slightly_smiling_face:

3 Likes

Yes! Some large partnerships is fundamental for some world class apps and … for the templates, scale and the mutual dataplume we need … and to establish the safe layer as a global operating standard. I remember your comment some years ago that we need our open ai type partnership that can be/will remain free large proprietal platform influence. :slightly_smiling_face:

It’s a problem with Safenet being organizationally centralized in these early days. I think we need to seek a way out of it some day, perhaps that would involve rethinking current fundamental protocol rules like royalties to the Foundation…

3 Likes