Well the same as the SAFE protects the PtD coin address stored there.
But thatās just a wallet address right, so it canāt be abused. Storing a private key is another matter.
Yes @cretz you and I are scratching or heads over the same question: why would I want to run an App that sends data to the app author? Sounds like Windows 10 to me 
Do you have a use case @neo? This is the bit Iām not getting. The SAFEpress solution I outlined earlier suddenly seems more appropriate and elegant than I thought. Also looking forward to @Senecaās protocol and what can be done with that.
EDIT: OK @neo your mention of stock control below gives me a use case, just not one that Iāve been thinking about. Itās enough though - I read this proposal as finding ways to do existing centralised systems without servers? Or do you have other things in mind?
I think it would be good to come up with some ādesign patternsā for Apps. Then we could map existing apps to these patterns, show the differences between patterns, and highlight new opportunities for different kinds of app than weāre used to. This would also demonstrate the benefits, OK differences, between doing existing apps on SAFEnetwork versus using centralised servers on an insecure and vulnerable internet.
4 Likes
The owner supplies the keys stored in the meta data. There is no requirement that the identification of the āownerā be known. The APP doesnāt own its own keys, but the person who set it up.
But of course if the person who setup the APP may wish the world to know the are, like a shop, or quiz company or whatever that wants real-time updates.
Anyhow there is so much to benefit if real time updating of SD data without the user running the APP owning the SD data. Passing messages/SD objects around requires a āserverā to be running in order to provide even the illusion of near-realtime updates. Using the shop example, without real-time updates, even having a āserverā running 24/7 processing the messages/SDs sent to it could easily see over selling of stock unnecessarily.
We want to improve on the old internet not return to the 80s/90s without accurate stock control.
######(please the stock control is just an example of real-time update needs, there are 1000ās of others so donāt pick that example apart, because then you have to find holes in the others which are doing different things)
1 Like
Ummm yes there are 1000ās. What do you think the millions of server-client systems are doing.
I can tell you they are not sending little emails/messages from the client to the server, but the client is talking to the server directly and the server updates its database in real time.
So how can we do that when we remove the server?
Now if I wanted to implement a stock control system and shop front I can have SD objects store my stock information and let the APP update them directly. Easy to do in SAFE. BUT BUT its not secure because as far as I know at this time I would have to store the credentials for the SD objects in the APP and that is a no-no for security.
Internet shops today have the luxury of real time stock control and teh customer can have confidence that if the ordering system says the stock is there that the store can send it.
But without real-time updates that is not possible, so why would they choose SAFE to develop an APP on.
Passing messages that hold the info and/or SD address of the SD with the info, is going back to the old days of the 80ās and early 90ās when online systems (X25, internet/web) received a message with the customer info and the stock updated when the order is processed after reading the message/email. On line stock levels just could not be done because the timeing was shocking.
And to make it worse is crippling SAFE with server backends to do what should be able to be done natively with APPs
The APP writing the customer order to a SD the customer owns then transferring it to the shop, is bad for business because then a backend āserver/deamonā machine has to be running. So why use SAFE, easier to do on the old internet and the old internet gives real-time updates
2 Likes
Well let your mind loose and think of all the things that require real time updates.
Many are solved purely by messages because the person/device sending the information does not need the info. EG monitoring IoT devices etc.
But things like stock control, physical auction houses, manufacturing systems that use JIT manufacturing heavily rely on instant up to date stock levels. Or to track the process in real time.
I am thinking ahead when we can have a manufacturing system that ONLY has user stations and no need for central server to receive all the updates from the user stations and keep the database updated centrally and provide real-time info essential for JIT manufacturing. Lets eliminate the requirement for a āserverā to keep everything updated.
Each station has its job to do and the APP updates the SDs (for this example). One is updating such-n-such use of items in the manufacturing. One APP is handling the ordering of new stock, one APP is handling the warehouse receipts, one APP is handling account keeping. ALL without the requirement for a server. Done this on a peer to peer network in the 80ās, but SAFE offers so much more and the ability to do on a global scale, but the security of SD credentials is essential.
Yes we can do work-a-rounds which I have done for decades to fit square peg systems into round holed systems. But why should we? And I was SIMPLY ASKING if this protection of SD credentials had been considered. I did not think I had to justify the simple question
Having the need for ācentralisedā data is not foreign to decentralised systems. If we want to appeal to businesses then being able to supply storage is a big plus, but to be able to offer secure APPs that can operate on a businessās SDs objects while keeping the credentials safe is a huge bonus. SD objects are going to be the rocket fuel for SAFE and to allow secure access by APPs to centrally owned SD objects is essential.
2 Likes
What I would like is the ability to let clients subscribe to notifications (PUSH from the close group(s)) on changes to a particular SD address.
In Decorumās protocol, a reply to another SD (which could also mean a purchase order if weāre talking commerce) is a new SD at a deterministic address (hash of the parent address + reply index). So I would define available product(s) in a SD, and let the replies be orders of that product. The app(s) would contain the rules what constitute as a valid order, so anyone can just GET the reply list and know how many valid orders were made, and thus how much stock is left.
However, right now everyone would need to poll for any replies, but being able to subscribe to the next unused reply address would get you a real-time notification when a new order is placed. When that happens you subscribe to the next unused reply address.
1 Like
Could you do this with messaging? The APP changes the SD and send messages to the address(es) set up. Obviously no good if you want more then a few of addresses notified[quote=āSeneca, post:67, topic:8294ā]
So I would define available product(s) in a SD, and let the replies be orders of that product. The app(s) would contain the rules what constitute as a valid order, so anyone can just GET the reply list and know how many valid orders were made, and thus how much stock is left.
[/quote]
So if I have 100000 widgets and they are sold in lots of one or more and they sell like hotcakes, then each user running the APP might have to read 10ās of thousands of SDs to tally how many have been sold. No business or smart software would do that
1 Like
I think that any system that indexes data in real time that requires central ownership of the SDs will require this too. Or messy work-a-rounds will have to be devised and potentially make the overall application to slow/messy/unworkable to be of interest to users, and someone will just make a server-client version.
So indexing can be done with the end user owning the SDs and if needed transferring ownership. But many would benefit greatly with real-time update of the SDs.rather than having to scan perhaps a million SD to get the actual figures.
In particular a server/backend-less database style of APP that accesses public or private records and to have only user owned SD units might not be a good idea. Especially when multiple users have to update the one SD record and you donāt want to see users having fun messing up the indexes. encrypting/serialising the data can only give you a level of confidence the data is good/bad, but the messed up existing data is still lost even if you know that it is.
2 Likes
Being a developer in such a system Iāve been thinking about this a lot. I think there are a lot of reasons you would need data transferred to the āownersā of these kinds of apps. Ordering, invoicing and everything ERP. Most shop owners, etc.
Most of the time transactional data isnāt good on document type data storage. You want a more relational model traditionally for these. This is going to be interesting to try to figure out.
Good practices become patterns, not the other way around.
4 Likes
You donāt have to GET every single one of them to find the last unused one, you can use a half-interval search for that. O(log n), so in your example at most 17 GETs. An order can be kept very small, say about 200 bytes. Thatās only 3.4 KB everyone would have to download, at max.
There are ofc other details that need to be taken care of, but Iām not designing an order book system, so I havenāt given them much thought. Itās just an example.
1 Like
Well you did say list.
But how do you keep stock level if you skip them all. Do you address SD using previous SD address + 1? Otherwise you cannot do a binary search. That is so prone to error and being ever so wasteful of resources. 100000 SD just so you can know how many were bought,
So even being able to use binary search is still not going to be endearing to business/software developers.
If the client appās search ends up at reply index 80,000 and in parent SD it says there are 100,000 available, then you know there is one available and you can order one. If you want more than one, you go from there to see if there are more empty addresses. Client doesnāt need to know the exact stock number, just whether the amount the client wishes to buy is available.
No, parent_address+order index, so you can pre-calc them all once you know the product SD.
Only the seller has to do that, and itās not really different to receiving 100,000 messages at your server directly from the customers. 100,000 sounds like a lot, but if you express it in terms of data, then it hardly is. Also, decentralised trust/consensus is less efficient in general, there are upsides and downsides compared to client-server model.
Oh its a whole lot different. Remember that messages in ones outbox is limited to like 10000 from what David says.
Why have 100000 SDs for one product??? why not have the one and realtime update. Saving all that real resource being wasted.
Imagine the local shop like DX with over 100000 products and some with a huge number on hand. Then umart, msy. That could mean billions of SD elements for just a few shops.
It is not sustainable. And certainly against good practices.
And it is going to be billions of stock records when it could be a million or 2 and the # of orders in the āinboxā will be magnitudes smaller than your stock records.
Add to the protocol that a valid order should have shared ownership with the seller. When the entire batch is sold, all SDās get a DELETE from the seller to clean up the network. A backup of all of them can be written to one immutable data file, which has the least overhead for the network.
An SD can be just a temporary record, I donāt see why itād much more wasteful compared to another kind of message. You try to make it sound like SDās are these huge bulky things with gigantic overhead, but they arenāt, especially not considering we are talking decentralised, anonymous communication here.
Also, none is saying that every product in the world should be sold in an anonymous decentralised network. Especially if you ship stuff, in most cases thereās really no room nor need for SAFEās level of anonimity and privacy.
1 Like
Anyway, this discussion is taking up too much time for me right now, so Iām out.
1 Like
I want everything on safe 
or I should say I want everything to be able to use safe and for safe to be THE BEST solution for all data. I know this is probably naive (golden hammer) in thinking, but Iām hopingā¦
3 Likes
Iām very much of the opinion that writing to someone elseās data shouldnāt really be something you can do.
The SAFE network is about privacy and security. If writing to someone elseās data is allowed without compromising the security of the person whose data youāre writing to, it just incentivizes people to start hoovering up data ownership; in the end weāre back where we started: The user isnāt the one who controls/profits from the data they produce. Not being able to write to someone elseās data is a security feature essential to keeping the network decentralized. It is not a bug.
So a store owner cannot own their own product data and lets customers access it and the store APP update it. ?
Its not about letting people gain access to others data, but a limited use case where someone lets others update their data. Its up the user if they want to use it. And Iād say they will if they want to buy from the store.
The difference is that you talk of gaining access to other peoples data but this is the other way around, allowing others to access your data for the purpose of updating it for the userās purpose.
Yes. This is exactly what I want to stop people from doing.
If, say, Google took a shine to the SAFE network, what percentage of data do you think theyād allow you to write to your own data stores and what percentage theyād force you to write to their data stores if this was possible without compromising security?
I think those percentages would hover around the 0% and 100% marks respectively.
THIS is why itās important not to allow posting data as another user without their keys.