Amazing angle to take, that is genius! We are all very excited for your application. It is the killer apps that will take the SAFE Network to the mainstream audience. Let me know if you need anything!
5 Likes
I hope this is an understandable explanation on how I plan to create Decorum’s SAFE utility alt-coin:
It’s a bit long, but well worth a read I believe. That post is mostly about the proces of creating an alt-coin, there is a lot more to be said about how the Decorum coin is used in practice when used for content promotion. That’s a discussion for another thread.
6 Likes
That is great news. Just make sure that the University does not gain (any) rights to your submitted thesis and the research done in it.
5 Likes
Absolutely fascinating idea!
Count me in for support, would love to see this vision realised!
4 Likes
Just out of curiosity, not hurrying you up or anything, but do you intend to release a 0.1 version just after SAFE be launched?
It would be great to have a MVP (this word is very popular nowadays) that you can improve on future. I think you are the best guy to make this type of software, but if you wait 2 or 3 months, some pages will appear, each one which its own way to manage comments/posts/etc. And after we had a lots of comments, it will be hard to make a migration (it will depends on commenters updating their own comments to your protocol).
3 Likes
I intend to release a 0.1 version as soon as possible, but the MVP won’t include API support for StructuredData objects which are necessary for any dynamic data like comment posts. So we’ll have to wait a while after MVP release.
4 Likes
That’s one of the parts that will be so interesting and that I honestly don’t understand very well.
1 Like
Yeah, I’ve been struggling with the prospect of editing posts. With server backend, there’s virtually no overhead, but with the Network, there’s a price - either upfront in the form of SD, or per-edit by submitting new ImmD types.
Technical issues of linking SD types aside, I think that’s the way to go. More of a forum instead of a mailing list.
You sonofabitch that’s awesome.
1 Like
Why do you think SD is a requirement for comment posts? As in, why wouldn’t using “regular” data in a virtual drive work, at least for the MVP?
1 Like
Are you suggestion that it could be optional whether the user wished to create a StructuredData object as a comment (editable) or an ImmutableData object (cost-per-edit)?
It is my understanding that SD will be far more expensive that regular immutable data (someone correct me if I’m wrong) due to the ability to edit is as many times as needed. I don’t foresee a ton of people editing their forum posts all the time, so it would probably be more cost effective to use immutable objects.
But my question was more along the lines of why @Seneca wanted to release an MPV without comments rather than just using immutable data.
You commented above:
I’m not sure why you think it would be like a mailing list. When you “overwrite” immutable data, it acts in a data versioning-type scheme. So essentially, to someone requesting the same object, it would look like an update. You’re just paying for every update.
1 Like
Well, SD should be far more expensive.
Which should be good. Fewer moronic comments, less spam.
3 Likes
Because as far as I know there’s no other way to get predictable adresses for comments, which is necessary if we want to keep it fully decentralised (no central coördinator or server). An immutable chunk’s address is the SHA-512 of the entire thing, so the content of the comment affects it’s address. An SD object’s address is just the SHA-512 of the tag_type + identifier, which are free to choose and independent of the comment content.
So using SD objects, we can establish the rule that the identifier of a reply to a post is SHA-512(parent_address + reply_index). That means that given a post, for example reply number 1 can always be found under address SHA-512(tag_type + SHA-512(parent_address + 1)). The application implementation knows that rule and can thus “search” the SAFE network for any replies to any post.
I don’t know how such a scheme could be implemented with immutable data only.
Last I heard it will be 1 MB, so roughly 10 times as expensive as immutable data.
Fixed that. StructuredData will exist in the MVP, just no API support for them immediately.
1 Like
SD object is 100KB total
It is 10x cost because creating an SD is the same cost as Putting a 1MB chunk
Indeed, I meant the cost to upload is 1 MB in SafeCoin (immutable data price), not that the SD object can be 1 MB. And I said roughly because 1 MB is 1,024 KB.
1 Like
The thing is, a PUT is a PUT, as far as I understand. A 100kb max. SD PUT is the same cost as a 1mb max. Immutable PUT, regardless of the actual size of the chunk.
But how long are most forum or comment posts? You’re not going to be using more than 100kb, even if you post it as Immutable, so much the best to have the control that SD gives==edit, delete. It will cost the same as long as the post isn’t over 100kb.
That’s my understanding on how you purchase data, i.e., by number of PUTs, not absolute data volume. Am I wrong on that?
4 Likes
That is my understanding too. And David has said the same thing. Even the 1MB chunk is not entirely right too, because it can be range in size from a few KB to 1MB AND it still cost one PUT cost no matter its size
The SD PUT charge is also includes the creation of the SD and the future rights to re-write it too. Its a great data structure to be included in SAFE[quote=“fergish, post:98, topic:6119”]
But how long are most forum or comment posts? You’re not going to be using more than 100kb, even if you post it as Immutable, so much the best to have the control that SD gives==edit, delete. It will cost the same as long as the post isn’t over 100kb.
[/quote]
Exactly.
Had a thought that a lot of forums put a time limit of how old a post can be and still be edited. So the forum s/w could move the older posts of a long topic over to immutable data and release a bunch of SDs to be used elsewhere
Do you have a source for this claim? I’m looking at the NSF API documentation, and you provide a set path when modifying information. I’m assuming this is the API for immutable data, such that behind the scenes it removes the latest reference to the old objects and creates a reference to the new immutable object.
Agreed, when it comes to collections, I don’t see how immutable data can be used. However, this begs the question: what use cases will immutable data have in most applications? All data in an application needs to be predictably reference-able from somewhere, otherwise it’ll never be found. Whether we’re talking about a list of subreddits, threads, comments, likes, donation lists, whatever, since everyone “shares” access to SD objects, I don’t currently see how anything else can be used; immutable objects aren’t share the same way.
This also begs the question: why not have SD that is both immutable and mutable? If a tag_type + identifier is set as immutable, it will cost less (same as the current immutable data), and if mutable, make it 10x more. That way both types of objects would be shared, and whether it’s immutable or not would depend on its usage.
I’m trying to fill in the gaps of my understanding to the best of my ability in order to build out the JS library. The idea is to abstract as much of the technical aspects away as possible and make it easy for the average dev to use.
1 Like
The SAFE NFS can be considered a layer on top of the DHT layer, it’s use is to organize your own personalised virtual drive. Changing a path in the NFS only changes the virtual location of your reference to that data, on the DHT level nothing changes.
3 Likes