For making things like a store, market etc. Why not use some sort of transaction ledger. You could put up your product for sale, someone else could fill the order and a group of others sign the transaction and you’re done.
why not just have the inventory held in the apps public data or a directory on SAFE and when a user buys an item, a message is sent to reduce the number of inventory displayed via the apps public data by the amount of items purchased.
This would update the inventory for all users to see so the app would be receiving a ton of messages, not the users…this would have the user initiating the contact with the app, not vice versa
I was thinking about this issue earlier again and it struck me that we may be looking at this in the wrong way. We are trying to apply traditional application design patterns, which may not fit.
Perhaps what we actually need is an automated escrow service. That is, we define and SD which defines a contract, which the network itself can act on once the conditions are met.
For example, you could create am escrow SD with 2 input requirements and and 2 output actions. The inputs could be the following (in order):
100 Safecoin SDs are given a secondary owner (the escrow ‘virtual’ user.
1 stock item SD are given a secondary owner (the escrow ‘virtual’ user.
The outputs could be:
.3. 100 Safecoin from 1 are transferred to the primary owner of 2.
.4. Stock from 2 are transferred to the primary owner of the Safecoin from 1.
As the contract is clear, the network could apply the outputs as soon as the last requirement is fulfilled. There are no tricky algorithms or or app users as such - the network just applies the mutations as part of its SD handling routines.
Moreover, you could chain such escrow contracts. The output from one could be fed to the input of another, e.g.
.3. 95 Safecoin from 1 are transferred to the primary owner of 2.
.4. Stock from 2 are transferred to the primary owner of the Safecoin from 1.
.5. 5 Safecoin from 1 are given a secondary owner of another escrow (say, a delivery service, which has another deliver service product token/SD as an input).
You could set it so that any party could bail and the contract would return all SDs to previous owners. Once fulfilled though, the outputs could be completed atomically.
@dirvine, is this sort of thing possible? It could be very powerful.
Incidentally, it would be very simple to create a proxy escrow contract too with this. You could then use it to scrub ownership on transactions sent/received automatically, if desired (or do other transformations).
I shortly mentioned it earlier, but this sounds as Ethereum-like smart contracts. Rules are defined in it, assets (tokens) are stored in it, people can send a transaction to it with a certain amount of coins, and if the format of the transaction is correct, the code will be executed by the close group and assets transferred as a result. Or in this particular example, a record of purchase is added to the data of the smart contract.
How does the user running the APP change the ownership on the shop’s stock item[quote=“Traktion, post:86, topic:8294”]
.4. Stock from 2 are transferred to the primary owner of the Safecoin from 1.
[/quote]
This still requires a “backend” to do the change in the SD holding the stock level.
Or are you suggesting that the APP can.
Anyhow I doubt it would work anyhow without a backend. Some APP has to update the stock levels and passing around SD objects negates real-time updates.
No, ALL that is needed is for an APP to be able to (re)write SD objects that are set by the person setting up the APP. AND the credentials are secure. The first part can be done already, the question is can we do the other part yet.
No need for complexity of contracts, escrow, shuffling messages around, backend servers, one SD per stock item, and all the other workarounds suggested. And ALL the work-a-rounds do not give real-time updates.
Yes I did consider that early on. I’d say though that with the original question conflated with other issues and the example taken as the actual question, that a followup topic might just follow the same path.
The dev updates do at times end up discussing one issue of the upcoming release. This has revolved around the SD RFC
I think this needs 2 or more topics. One just for the example I used and the other for the actual issue and that is how to store SD credentials for SDs and not do the unforgivable and put them into the code/data of the APP
Not yet, my point is that that is required to do this:
Because your proposal to store the private key of the app that has access to the SD in meta (along with the PtD wallet address) doesn’t make sense. A SAFE file’s metadata is not secure, the wallet address isn’t a credential, it’s like the hash of a public key. AFAIK, the only thing the close groups do with it is occasionally sending a new SafeCoin to it as a dev reward. If you store a private key there for SD access, anyone in the close group can just grab it and start abusing it or just sell it.
You also want to the close groups to validate that the input into the SD is “proper”, i.e. in a format that is a valid output of the app in question (rather than some sabotaging trash or spam). This is equivalent to enforcing smart contract rules, it needs a DSL to support customization and probably compensation for the close group to do that job.
The shop owner assigns the escrow virtual user as a second owner when the stock is made available. The escrow virtual user can then change the ownership of the stock item once the contract has been fulfilled.
The stock can just be the stock items waiting in escrow, made available by the shop owner.
These stock items could be the only ones shown to the customer through the shop UI. That is, items not held in escrow could be filtered out, as they couldn’t be purchased directly in that state.
I would imagine that the shop would break down stock items into categories, sub categories, products, so the query list to filter should remain relatively small.
The shop could also give visibility to stock items which were no yet available (e.g. on order). These could be stock items not yet in escrow.
I would say this isn’t a work around, but an embracing of how the safe network operates. Simple, predefined state changes of SDs are much easier to manage securely and quickly than arbitrary code blocks.
I think any non-workaround mustn’t rely on users executing stuff as another user too. If we can push such operations to the network level - to code near to the SD storage/retrieval code - then we avoid such complexities.
Yeah, private keys should stay private. On your system only. No need to share it with a group because you can always prove you have that key with a signature. With you only you owning the private key and not sharing it, you sign whatever you want and can do the same as if the whole group would have it. Without the key being stolen by someone else.
Not even a problem being discussed. Its the update of stock totals in the shop’s SD
So if I have 1 million individual items to shift then we are creating a massive amount of resource for maybe a shop selling 1000 different items
Again it is ONLY updating the stock left for for that stock item. The rest is so straight forward I am wondering why we are setting up complex escrow etc.
Since when. Its all secure. One of the criteria is that the PtP/PtD address cannot be revealed to 3rd parties.
You know he/we are referring to keys for real-time update of SDs that are NOT to be owned by the APP user. And the issue is how to do it without storing them in the APP
Anyhow knock yourselves out, the original question has been conflated with whatever people think I was really meaning. The original question was simple. But some think the example to illustrate a specific point is the question. No its not, and I doubt any dev can work out what I was asking because its so hidden
You asked how the ownership could be changed on the stock item. I gave you an answer.
Massive amount of resource? How so? The stock item SD would only need to store meta data about the stock item (perhaps even just a key to the associated product) in addition to the standard SD properties. I don’t consider either as onerous amount of data - even a relational database based shop may store stock items as records, along with their serial numbers, etc.
Moreover, SDs are mutable and can be removed/recycled as required. A shop app could easily maintain a pool of stock items. Shoppers who received the stock item SD as a receipt could also delete them when they no longer need it (a handy double usage though).
It may sound like a simple use case, but the same problem is there for both trivial and complex examples - how can associated data owned by a third party be updated by a different user with no access. Grouping these events atomically is also important.
Whether it is a stock counter increment or a chain of complex data mutations, this same route issue is a problem.
Actually I didn’t that was other people trying to suggest such things. I just wanted the APP to update an SD the user running the APP did not own. AND do it securely. No transfer of any ownership. My question has been so conflated and confused that no one can see the question anymore.
It seem you suggested having a SD for each of 1000’s of a widget and 10000’s of SDs for the 10000’s of number 2 screw and a SD for each and every single piece of every item that the shop is selling.
Piece of cake if you don’t worry about security, the APP holds the credentials in its code/data for the SDs. And all I was asking the devs was if there was any thoughts on having a function where the credentials could be held in say the meta-data and SAFE applies the credentials on behalf of the APP. But all I got was tons of solutions to a problem I was not asking.
That’s because the question doesn’t make sense. The proposal doesn’t achieve anything by itself, because the app runs on the client side, not in a virtual machine in the close group. From the close group’s perspective there is no difference between user’s output and app’s output, so it would also take garbage input and then happily “applies the credentials on behalf of the APP”. There is no gain in security in this proposal, the SD’s belonging to the app can still be sabotaged.
Also, if you don’t want other people sharing their views, use a PM… If it’s public I’ll comment on anything that interests me.
That’s because the question doesn’t make sense. The proposal doesn’t achieve anything by itself, because the app runs on the client side, not in a virtual machine in the close group.
Isn’t that what he was asking - if this was something that could be implemented to happen in the close group?
Perhaps, if so I didn’t pick up on that specifically. But then in my view that would be pretty much Ethereum-style smart contract functionality. Such a smart contract is an app executed by the miners (or in this case close groups).