Protocols for sale?

There’s obviously the NRS thread talking of the distribution of names but I wonder that for all the idea of safe:// is nice, would there be good use case to sell nameyourownprotocol name:// ?

I’m expecting the network cares not about the protocol and everything is about the xor and this perhaps doesn’t quite work as xors would still be visible to users of another protocol?

Still, I wonder there would be an easy sell on the idea that certain interest group could have a space they own without access to everything else.

Perhaps this is how private data might work?.. perhaps a protocol for private spaces that limits access to public data would be helpful?

If an authority can confirm who is, you could take an extreme example of a school accessible only to those confirmed as teacher and students, that would allow a limiting environment which is free to explore.

Tempting this as the inversion of intent is sometimes a way to test what is robust… but also that marketing is easy where there are simple toggle to answer any perspective. :thinking:

Perhaps change the default protocol from safe:// to “>>safe://” or something similar? Then, “>>name://”
might be feasible.

One of the reasons the web is universal is that everyone uses the same URL standard. As soon as you break that up, one of the most valuable features is lost.


As far as I can see, the protocol designation is the fundamental level of the network. To name a different protocol would be a fork, requiring a whole new infrastructure.

The code is open source so, sure, it could and undoubtedly will be done for various purposes, but you’d lose the network advantage.

I think subdomains could be done effectively, permissioned access, etc.

That’s just my non-techie thoughts.


Not sure that’s true. Private data surely will be similar.
Useful to hammer out where the limit lies, save debate in future.

Obviously having public data in one place is nice… but there will be private use cases. The option to have a distinct boundary might be useful to those who want focus on their own interest without even the possibility of mix.

There again, I think the lack of possibility would be defined by the network boundary. Even the SafeNetwork is built on an underlying transfer protocol system shared by all computers. To my understanding, safe:// is the fundamental context the the entire uniqueness of Safe takes place under. It is THE thing that binds the nodes of the network in a cooperative activity. So what defines “possibility” is the internal workings of the safe:// protocol, which is designed to be internally cohesive. xsafe:// would have to group a different physical infrastructure for it to be meaningful.

That said, I do thing that there will a high degree of flexibility on the safe:// network for having permissioned “subdomains”.

Again, just my conceptual grasp. Others with better tech understanding can comment if I’m wrong or right.


Is it safe:// or xor that is central?..

Granted its an odd thought but then multiple use cases piling on, makes a more robust use of data de-duplication.

RDF was suggested in the NRS thread but that requires the index is read every occasion to filter context.

I think private data usage may answer certain use cases but unclear atm how access would be managed.

What we would not want is tendency to use private data option rather than public, just to achieve focus on what data is… otherwise there’s risk of ending up with drm in effect.

1 Like

It is unquestionably safe:// that is central.

xor is simply a tool that can be used in various ways. Another implementation could use xor to organize itself and it would have no meaning within the context of safe://. “safe://”, to my understanding, IS the implementation of the SafeNetwork. The technology is open source, so one could implement it and call it something else, but it would be a discreet implementation with its own infrastructure.

Two chunks with the same xor address on different networks might hold the same data (if encrypted and hashed the same), but the infrastructure to fit it with its other pieces and deliver it is confined to the domain. Security and privacy depend on the integrity of the whole ball of wax.

edit: Of course, I’m looking from a non-geek, high altitude view and so may be really unaware of something. So, if I’m wrong, I’d love comment from someone more savvy. :thinking:

1 Like

Spot on, but also the chunks are signed and this is really critical. For a chunk to exist on Safe it is valid, if it:

1: Passes integrity (so for us hash content == name)
2: Is signed by a section key in this section.

Pt 2 is critical as no node can refuse to store that kind of data, if it did not then it is punished.


I’d say no. It’s possible to do it, but there’s no benefit to it.

Specifically on selling, what value is being created that allows it to be ‘sold’?

In the more general sense, ‘using’ rather than ‘selling’, what’s the benefit of using it instead of safe://?

The protocol part of the url (ie the bit befor the ://) tells the browser / app etc what to do with everything that comes after it.

SafeNetwork cares very much about the protocol. That’s what it is - a new protocol to get data from here to there without servers (p2p) and without data loss (permanent).

http is a protocol for clients to talk to servers.

websockets is a protocol for clients and servers to talk to each other (bidirectional).

safe is a protocol to talk to safe network nodes.

Anyone fetching data from the safe network (even if the data is wrapped up by the client in a unique way) must talk the correct protocol, ie the safe:// protocol.

If the client is doing some extra authentication before the safe network request, then maybe that’s a case where a new protocol would be worth specifying (but probably not).

If the client is doing some extra decryption or data modifications after the safe network request, that’s not a case for a new protocol, just use the querystring or fragment.

For sure.

I think a lot of people will run servers (normal http servers or ftp servers or irc servers etc) that talk to safe network behind the scenes. This is an interesting fuzzing of language because the client (user) sees a standard http/ftp/irc server, but the safe network will see that very same server as just another safe network client (ie not a safe network node). The server acts as a client of the safe network (I guess the normal word would be a proxy). The terminology can get confusing very fast when different protocols get mashed together.

Underneath it though, the protocol is still safe://. Even if it’s wrapped up by some other protocol, it’s still safe:// whenever the request is dealing with nodes on the safe network.

Good question. I’d say xor is what’s central to the nodes, and safe:// is what’s central to clients.

An advanced client will never use safe:// in their code, they would only use the raw xorname bytes (and some assosciated metadata). But they may show their users a safe:// url since it’s an easy way to encode the necessary information for any future requests.

There’s a ‘private data’ flag that SN nodes will check and only respond with the data if ownership has been proven in the request. This is part of the protocol (ie nodes act on it, it’s not just a convenience for clients to use).

There’s a second more general type of private data which is encrypted data (which may be publicly uploaded and the plaintext content still remains private to whoever encrypted it). This is more like a third-party add-on type of thing and isn’t the responsibility of safe network or the network protocols.

If I’m considering implementing myownprotocol:// that stores data on safe network, the distinction between these two types of private data is important. But in normal situations it’s not important and just use safe://.

This gets to an important point about access, which will probably be on a spectrum of permissions.

Private data for 1 person (small whitelist, like my personal config files).

Private data for multiple people (large whitelist, like a family shared photo album).

Private data for all except some (large blacklist, like adblocker lists or robots.txt for aggresive search engine crawlers)

Private data for all (no read restrictions but data can be deleted if needed)

Public data (can’t be deleted)

Currently I think permissions are only whitelist but I’d anticipate seeing blacklist added too at some point in the future.


Very helpful post there. Thanks

I wonder that risks being more attractive than public data… or will that be necessarily more expensive to host and then cost more?

1 Like

I don’t think for sale … as it seems like new protocols would be far and few between.

I could imagine down the road there being say a really popular open source game engine developed that could be built into the browser, then we could have game:// … but even then, not necessary really as resource would identify what the browser needs to activate anyway.

However with WASM, everything really opens up and so we can just do it all with safe://

K.I.S.S. is best practice IMO.

Fabulous expansion @mav ! I’m much learnified! Thanks.