Discuss - 0027- append-by-all-structured-data-type

[rossmuir]

RFC > https://github.com/maidsafe/rfcs/tree/master/text/0027-append-by-all-structured-data-type Forum > https://forum.safenetwork.io/t/rfc-dynamic-data-support/8471

[maqi]

I think allows all opens a huge hole to the public, as anyone can put in anything they want. I think the dynamic data mentioned in this rfc is actually not a public data but a private data, as in the real world, it is stored on a server and can only be modified by the owner provided hosting code. which means every operation to such data is actually escrowed.

So, a type 8 shall be: anyone can be a requester, but must bearing a signature it has been approved by the owner.

To provide such escrow, the owner needs to have some hosting script running, to accept the request from public, and reply with a signature.

We also need to remember that sd is versionless (overwritten by the latest version), and this type_tag 8 is aiming for ANY payload. This makes it totally different to the transactions or smart contracts stuff, as the latter won't overwrite the previous version.

[cretz]

Quick points (I posted in the forum, but I guess this is the better discussion place):

1. Not sure this will be used very much considering the free-for-all editing nature. I know I won't use it.
2. There is discussion in the RFC about the launcher API yet there is no structured data HTTP API. Does it refer to #77?
3. Why is the word "append" used in the RFC when it appears to not have anything to do with appending. Am I confused on the definition of "append" for how it is used here? Or could this also be known as "replace-by-all-structured-data-type"?
4. One of the stated problems this is supposed to fix is "If it has multiple owners, then at least (n/2) + 1 owners must sign the Structured Data for any update or delete." In addition to this, wouldn't a more prudent approach be to make a type tag that support editing by any single owner of the set of owners?

[dirvine]

I think type 8 data should only allow

1. Addition of a hash representing a comment (so it's an immutabledata chunk).
2. On adding such a comment or appended peice of data for anything your publicKey should be added as well.

The internal structure then is a list of <SHA512>, <PublicKey>

Requires a mechanism to handle data overflows as well

[happybeing]

I don't understand the point of this proposal given the stated drawbacks. It appears to result in a system that is terribly vulnerable to sabotage, and so only useful within exclusively benign circles. Being vulnerable to censorship is not going to go down well with the SAFE community I think, to say the least! ;-)

I like the idea of appendable SD for creating a root and branch structure that (if I understand correctly) can't be destroyed by an attacker, who could just create new garbage threads (topics), but be unable to sabotage existing threads (topics). Any new garbage threads (topics) could (if I understand correctly) be removed by the SD owner - or am I wrong on this? Are even existing threads (topics) able to be destroyed by anyone?

What I think is needed is a way for data to be submitted, which according to a flag will either be queued for approval, or immediately accepted. But which once formally approved, can only be altered by a those with explicit permission to do so (e.g the SD owner).

This can be achieved if the "approval" process makes a copy of submitted data. The cost to users of submitting posts could be reduced by allowing them to reuse am item of SD which they own (to hold each new submission), and which is public. Or they could submit using immutable data and bear the cost of they prefer. Submission could be via messaging (as in my SAFEpress musings), or perhaps a method could be devised based on this appendable SD type, where the submissions are appended by anyone, (but can only be modified by the SD owner). In this scenario, the user's client App could be designed to display submissions either immediately, or once marked as approved by the SD owner. But only the SD owner could alter them (delete or overwrite). This seems a more useful solution, but I'm not sure how well it scales because I think it could result in a lot of data access by a client reading these appendable SD.

BTW I think you should use http://forum.maidsafe.safenet in your example (not .net) :)

[cretz]

@theWebalyst - I think you're focusing too much on the forum use case because the RFC does. I just want a simple place to store data that can be updated by the people I say can update it. No need for any discussion about "append", "threads", "forums", etc. The worst thing that could happen is building in full blown moderation in this low level construct. The complication added by "flagging" things or "approval" or whatever else is an app problem, not a network one.

[dirvine]

I suspect there are narrow use cases for an append only structure though. One would be the owner can remove links (hashes). This will not be the only append type (I imagine whitelisted version will follow). So this can be seen as a logger/comments capability etc.). Perhaps with the constrains this append only type can suit some purpose. What we do want though is extendability by people.

I think if the publickey is kept beside the hash (which leads to immutableData) then there is a chance for owners to perhaps block (which is a requirement for more functionality - blacklist) here.

Perhaps we need a whitelist version and a blacklist version with very specific items that can be appended? I think for instance it would make project decorum and others happy? Interested what @theWebalyst and Seneca would think of this?

So constrain the inputs, (i.e. updates must be POST messages not Put) and allow a blacklist and whitelist type?

[happybeing]

@cretz forum is the use case in the RFC :). Yes, I was suggesting flags as an application decision (in order to illustrate the ways the functionality I suggested might be employed).

@dirvine I'm not clear what the functionality is. Is it append by anyone, entries overwritable by anyone... now with idea that owner could black/whitelist access? If so I think the level of protection this gives (e.g from DDoS) doesn't seem robust, and is dependent on how hard/easy it is to create new accounts/ids, which I think we want to be easy - enough to make DDoS effective in this case. I'm not sure that I understand the proposals properly yet though.

@cretz I'm interested in your use case too. Can you spell one out, maybe it can be included in the RFC so we can discuss "case 1", "case 2" etc

[happybeing]

@cretz just to clarify, I was describing the application needs, not the underlying network functionality. And I focus on forum because that is both in RFC and is similar to the use case I'm interested in.

[happybeing]

I'm excited that were getting into this at last :)

[dirvine]

@theWebalyst What I am proposing is not we allow replace all info but instead a Post message is sent by anyone to append to this data item. Only owners can edit / delete these appended items. To ensure integrity the only thing appendable is a hash. That hash points to immutableData which can be read just like any other.

Then we introduce a new immutableData type, SignedImmutableData and this type can be deleted by the owner. Then you can post a comment in a forum by adding such but remove your comment by removing the immutabledata (as it's signed it is OK). Reading the StructuredData shows the immutable chunk is gone - so empty comment.

[cretz]

@theWebalyst - I will never be able to enumerate all uses. So the building blocks need to be as primitive as possible. As an app, I can append things just fine for example. I can manage moderation, etc. I just need multiple people to be able to edit shared data. I think that is a core building block that other things can be built upon. Personally for me only, I will never use a data type that allows free for all alterations/appending. I will use other mechanisms (e.g. creating SD instead of editing and use an ID that makes it discoverable somehow) if I can. But it doesn't mean others don't have a need for it. I also believe structured data should be supported in the launcher API before special structured data is supported in the launcher API (as this RFC mentions).

[happybeing]

@dirvine thanks, much clearer now. I don't see the ability for appenders to delete as helpful - gives them control, but still makes it likely that deleting will undermine the application (e.g. deleting of blog comments / forum posts is generally not allowed, at least for more than a short time, for good reason).

@cretz thanks for explaining. I only asked for one use case ;-) but I understand what you're saying. I don't see any harm in looking for building blocks of varying levels. Agree that collaboration is important, but I think that's not the point of this proposal (hence the forum example). I think you could write a good RFC for something that meets your needs that can sit alongside anything that comes out of this.

[dirvine]

@theWebalyst I suppose as there is no signed immutable data at the moment then you would not be able to delete your chunks (comments) but the owner could (remove offensive perhaps). So maybe initially type 8 is append but only owner can remove?

The simpler the better until folks scream for more functionality.

[happybeing]

:+1: Sounds good :smile:

[cretz]

@theWebalyst - "I don't see any harm in looking for building blocks of varying levels" <-- this is very dangerous. It can cause scope creep that can keep a product from being released, it can increase the surface area of failure/maintenance/insecurity, etc. I can definitely write an RFC that sits alongside this. I will not be doing so unless I think it's absolutely necessary to occur at this low level though (I have already written one at #109). I strongly suggest that this product get the APIs around what exists and work towards incrementally improving that. It is always better to obtain app dev feedback based on apps they have built (or tried to), not that they will build.

[happybeing]

@cretz I said "looking for". What to build is a separate issue. Breathe!