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.
