Well the idea of having normal server hidden in XOR space is quite appealing, I guess time will tell how it turns out. It will be interesting to see how much bandwidth the network consumes over time.
I would guess that a number of IoT in a small related āapplicationā will have a more powerful āserverā node to communicate their data to and receive commands from.
Not a traditional server, but a server for intelligent IoT devices. E.G smart house with its in house āserverā
Doesnāt sound too appealing to meā¦
It introduces the Web into SAFE. That IMO is something that is antithetical to the idea of what the project is supposed to accomplish, which is a secure and private access to network resources.
This sounds very worrisome.
If I am accessing SAFE and click on a āwrong linkā I can end up on these leaky servers that can share my IP address info to anyone,
Which I have no problem with, but imagine if that was a possibility (risk) for everyone on SAFE.
Secondly, the idea turns SAFE into a low cost version of Amazon S3 for clear Web. Post and access static cloud data for cheap. Thatās it. Not bad, but not what was the idea at the beginning either.
Thirdly, if sites like those (public Web servers) existed, that would be the security standard of the network: if you knew you can end up visiting one, or loading beacons (or live malware) from one, that would be your expectation for privacy and security from all sites on the SAFE network.
Again, if there was a vote, I wouldnāt vote against (nor for), I just think the idea should raise eyebrows and implications should be considered.
1 Like
This is not about what is appealing to you, it is about what could be appealing to some and about what happens when some becomes too many.
But I think we are just not talking about the same thing. Clients wonāt be using IP directly to communicate with the server. The communication would always be through Safe messaging.
Hereās an example. Some guy runs a tic tac toe game server. The server is also a Safe app. The app listens on Safe for messages. The player runs a tic tac toe client, which is also a Safe app. In order for the client and the server to start communicating they need to find each others in the XOR space. The server updates a publicly known structured data with its XOR address. The client knows the address of the SD and gets the XOR address of the server from it. Then the client sends a game request to the server through the Safe messaging API and the server matches the client with another player to start a game of anonymous tic tac toe.
Of course this assume that: there is a messaging API and that a Safe app can register with the Safe launcher to receives messages from it.
If these assumption are correct, this means you can run a classic server on Safe while keeping the anonymity of your users. And this is why this could be appealing to a lot of people.
I think itās a neat idea but I also have concern for the performance of the network if too many people uses that. Which makes me think that the Safe network would not be able to completely replace the current internet because it adds on extra burden on its infrastructure by bouncing around every packet of data. IP is much more efficient. The users of Safe wouldnāt be able to handle the load of the internet. Which is why Iāve got concern if too many people start doing this.
Yeah, thereās no vote, itās just something people can do if they wish to and @Tim87 just pointed it out.
In that case - yes. However, why use the Network at all if they already know the IP addresses available to them?!
This proposed protocol is just not extensible to many use-cases that the Network is designed to facilitate - namely privacy out of the big three (privacy, security, freedom). However, ābest is the enemy of goodā, so Iām glad that weāre starting somewhere.
1 Like
I just stated my personal opinion. Didnāt imply it should be binding or even considered.
I see. Iām not one of them. I think such requirements can be better solved by running a small app server (say NodeJS) in the Launcher.
1 Like
Isnāt that what Iām saying? How does your clients communicate with this app?
Again, the clients doesnāt know the IP address. Itās only if you need multiple servers to handle your logic that these servers can communicate between them using IP, or not, itās up to the dev to decide. The users still connect through Safe.
- Itās really hard to tell. Look at Powersignās comment above, smaczās and mine here - perhaps thereās a remote possibility the idea was poorly explained?
Also halfway through this topic Tim said this āIām talking about a way to implement āclassicā client/server architecture within the confines of the SAFE network through existing (or planned? talking about messaging) functionality.ā which lead everyone who by then was suspecting that weāre talking about a built in app server, astray.
- How does my client communicate with NodeJS running inside of my own Launcher? Maybe I would use sockets, for example.
Server, IP addresses, Structured Data, what the hell?
If someone simply said the idea is to run NodeJS in the Launcher nobody would have misunderstood the concept.
Perhaps. Not sure how to do it better though, Iāll let us sleep on it some more.
EDIT:
Hereās a simple way to look at it.
Classic:ā¦Client sends messages over IP to server.
Safe:ā¦Client sends messages over Safe messaging API to server.
Itās just that. Why would people want to do this? To get the advantage of running a server but still being hidden by the Safe network. Think of the appeal of an anonymous Safe Poker server for example.
The part about the structured data is just a tool to find the server in the XOR space since this address will change whenever the server disconnect from Safe.
By clients I meant your users. People who wishes to use the service you provide.
Between nodes on the network, I would assume Safe messaging would be used. But itās an implementation detail, I would say of secondary importance for this topic.
Thatās clear now. And yes, that may be the best way to do it.
Again, I just find it confusing that the implementation details were mixed with the idea.
Dynamic data could be implemented in several ways. One could have ādynamic dataā without using any SD at all (that is, data that changes in RAM is also dynamic data, it doesnāt necessarily need to be saved anywhere to be dynamic).
For example you could have a list of 20 contacts (your friends) each of which could run a common service on top of NodeJS running within their Launcher. If you all agree to serve one particular set of data or an app, then I just need to go down my contact list and attempt to contact any one of them. There is no need for any SD in this scenario.
Or you could have a NodeJS app that gathers data submitted by the client until itās got 1MB of it and then dumps it on a public Web share.
Or you could have an app that doesnāt need any data at all. Maybe 6 of my friends have a special data-serving app which works on regular SAFE blocks, and I connect to any one of them to get data in a way my own client canāt process it.
None of these examples require SD so in summary it would have been easier to understand without the ideas for implementation details.
Ah, I think I get where the confusion comes from. You talk about ways to achieve dynamic data, this is normal since itās the title of the thread. I talk about about ways to have a server accessible through safe, which is also normal since itās what Tim talks about in the OP.
I blame @Tim87 for the confusion 
2 Likes
I think when the safenet go popular, all the problem will be solve , like the internet we are now using, back to 20th century, we were using static.
THEM: the servers operated by the same person, or a group of trusted operators ā they can communicate directly without implications concerning their anonymity, because they didnāt have anonymity within their group to start with
OTHERS: the people using the service run by those servers ā they need the SAFE network for its security/privacy/anonymity features
So:
- Vaults donāt implement messaging - itās MPID messaging: aka client-to-client only.
- The āserverā would have to be a client
- Clients donāt change their address (MPID) when restarting.
I see your point if youāre talking about having multiple āserversā on the SD ālistā and adding or subtracting them as necessary for load balancing - however, see (2.) below.
Also, this system youāre describing using messaging is high-latency, so donāt expect to do VoIP, MMO gaming, load balancing, etc. using this type of implementation. IP-to-IP is the only type of low-latency connection that can be achieved using the Network.
There is absolutely no need for a client-server architecture in this instance. This would be ridiculously easy to make on the Network itself.
This is a P2P architecture. Think front-end development.
- Have clients connect with each other over the Network in the app itself if youāre worried about matching up people and sec/priv/anon
- Establish IP-to-IP if youāre worried about latency or internal load-balancing
- Message one inbox directly if youāre worried about computational power.
- Also, spreading the work over your own servers would be best done with one inbox and internal load-balancing between servers at a deeper level than the SAFE Network provides - on the IP level.
This idea breaks the āstatelessnessā of the Network. This is 100%:
1 Like
Yeah the IP thing was weird, but maybe I would have taken that better if I understood what was actually being proposed.
Yep.
1 Like
Fraser in the Messaging RFC conversation
The intent is that the message contents and the Header subject
can be a serialised anything, so different apps will encode different
structures into the data field. Your app should therefore be able to
tell which messages are for it by parsing the Header.
Additionally, apps could perhaps create their own MPID on behalf of
the user to ensure that the messages for the MPID are all for it.
1 Like
My feeling is that we have only begun to scratch the extraordinary potential of combined use of SD, immutable data, and messaging. In a way we are bound to mindsets that must change in the SAFE network.
When I read for the first time, the RFC about SD remembered an old book from Niklaus Wirth who studied, a lot of years ago at the beginning of the university, entitled āAlgorithms + Data Structures = Programsā
I think the excess of specific technical details is blinding us and we must re-think all from basic programming logic.
Perhaps reread the classics can help us.
2 Likes
Iām not really sure what you are arguing against. If a developper find value in running a server behind Safe thereās nothing you can do about it. The possibility exist even if you think itās 100% antitheticall, again, we are just pointing it out.
Iām curious how you would create a poker safe app without a thrusted entity to deal the cards.
This is not completely related to your arguments, but unless there is a reason to have the site completely SAFE-based, why not simply run the app on a normal Web site?
Iif you need to output results or scores or something to the SAFE Network, that can be done using Fuse (run Safe Launcher, mount your SAFE disk, and dump results/reports/data to your public Web share on SAFE)
This doesnāt require any SAFE-specific engineering and allows the dev to have his app active on both the Web and SAFE, and the gateway approach was ādiscoveredā 2 years ago when people started wondering about SQL on SAFE.
Iām curious how you would create a poker safe app without a thrusted entity to deal the cards.
I am too. Using the blockchain that is probably possible. I donāt know how one would do that on SAFE where there is no blockchain.
1 Like