lol…nice[quote=“dirvine, post:12, topic:8294”]
There’s the meme it works
I like that and think we should start spreading it to combat FUD - Safenet…it works.
I’ve got to admit, I do find some of the Fud/trolls quite amusing. I recall that one bemused guy kept saying "Troon? Where the hell’s that?..and they can’t make software in Scotland!"
Another was putting people off saying "The lead dev is the village sailor and the COO, the village fireman!"
I say it doesn’t matter what passions drove you in your past, it’s the drive and passion of the “Now”. Why they pick on the main 2 devs I don’t know, apparently @Fraser used to be the village construction worker, @Ross the village New York traffic cop and @qi_ma the village native Indian…but they don’t pick on them do they?..No!
just want to mention (for the ones that seem to be slightly frustrated because they might lack the insight that helps to see the progress happening under the hood)
when you go to https://github.com/maidsafe/ you can see the repos are changing all the time =) (what exactly is being changed can be seen if you click on the little “forks” button on every repo - looks so nice all those branches that appear/getting merged together again )
and i encourage everybody who is interested to get some basic rust compiling knowlege … it is sooo cool to see the version numbers changing all the time … it feels like every day there are some major version changes in some of the repos =) so encouraging to see that good progress is made and from time to time there appear new tests, first some of them fail, then they pass - it’s so cool you can really follow the process and see where the problems seem to be hidden
thank you very much for this open process @DEVs =)
@Al_kafir I just watched The Village. If you haven’t, I think you might like it - its an interesting take on governance (and I’m not trying to make a point here - I just can’t resist the synchronicity of reading your post seconds later):
I have one question that has annoyed me for a while.
If an APP creates and rewrites its own SD elements, what is there to stop a cracker from rewriting the SD elements to change/destroy data. All the cracker has to do is grab the owner keys as the APP is running (in a sandbox if needed) then use those to do whatever they want to the SD objects.
The problem is that the cracker takes any good APP that keeps its own SDs. That includes cress learning APPs for instance. Or ones that involve buying selling goods - eg shop front APPs that keep orders submitted in their own SDs
Well then big picture, I see apps that store things in this way will fall out of favor, and devs will have to stop storing things this way, or risk losing all their users to other apps that don’t have this huge security problem
There are easy solutions, I am asking if and what MAIDsafe devs have done in this area. And it is important that APPs can own and control SDs elements.
Take shopfront APPs they need to ensure that orders made by customers are not changes/invalidated by the customer later on. So rather than let the customer be the owner (or joint owner) the APP has to own the SD. Joint ownership allows either of the two to change it.
I don’t really see it. In my mind there are just people, and the apps they use are merely translators to communicate over this digital medium. I don’t see an app as a third party. If someone messes with the app on his/her side, the translation will be considered garbage by others and thus ignored.
Then, as the shop owner, only accept orders when ownership of the SD in question is transfered to you? Again, I don’t see when “the app” as an independent actor would ever need to change the order. It’s either an action of the client or of the shop owner. If the client isn’t allowed to just do something, then it has to send a request to the shop owner, who accepts or denies that request and takes further steps.
So who/what does the transferring, is that not a function the APP would do?
I am not saying that
How is the shop owner going to do anything when you are running the APP on your computer. Its just the customer and the APP at that time. How is the shop owner going to even know an order was placed.[quote=“Seneca, post:36, topic:8294”]
If the client isn’t allowed to just do something, then it has to send a request to the shop owner, who accepts or denies that request and takes further steps.
Well isn’t that just the APP
displaying the products,
the customer chooses the products to order,
the APP writes the order to a SD object,
then the APP either
sends a message to the shop owner with the SD address
the APP writes to another SD and updates the order list with the address of the new order
Seriously if the customer is the one who owns the SD then it can and will cause issues if the customer changes the data in the SD. If the customer is to transfer ownership then why shouldn’t the APP do that. Why expect the customer to do some transfer independent of an APP???
The APP needs to update a SD that is owned by the store owner to bump the order# by one for each order. Also to keep stock levels, and a number of other functions.
OBVIOUSLY the APP doesn’t own the SDs, the shop owner does.
But the customer who is running the APP will never have control of the Stock level SDs or the Order# SD, but it will be the store owner.
The store owner has to embed the owner keys to their SDs into the APP and at that point the cracker simply runs the APP to extract the keys.
So I am asking if the MAIDsafe team have thought of this and if they have programmed in a way for the keys to be held in say the meta data for the APP rather than in the APP code.
Seriously why is this getting so much resistance.
I can think of 1000 reasons an APP needs to update a SD that belongs to the APP’s “owner” and not the person running the APP
It’s hard to believe that you cannot see the disadvantages of rushing any product to market, let alone one that has the world changing potential of the MAIDSAFE network. @dirvine wants this to work, the core dev want this to work, you and I and many many others want this to work and we want it to work right. Ironing out the creases before the release is SO important for a project like this, the last thing anyone wants is it to crash and burn the instant it falters. A joke’s a joke but, please be patient. These guys are working very hard and very efficiently, all for a non profit enterprise - for the greater good. We should be grateful, not disrespectful.
I always envisioned this as a daemon that is run on the Network in the future after the other features are added. That daemon would be in charge of any type of internal registry that is based on external input.
It may just be that at this point, it can’t be automated.
That is unless you want to jury-rig the system so that the internal registry daemon is run on an always-on client session responding in real-time to MPID messages. That would be a dirty hack though.