Topic: Decentralized Data Storage Cloud on the Blockchain... (Read 1132 times)

do you think they had this all planned out already?

It is clearly incomplete. Outside developers mostly need the Nxt API documents, and they are easy to understand.

The next big feature is child chains. There is no specification for that, but the developers seem to be able to produce working code without specifications.

I have respect for some (former and active) Nxt devs (e.g. Come-from-Beyond and jl777), but I think they need to write better specifications. I have personally told this to jl777.

What you have above is very incomplete.

I have respect for some (former and active) Nxt devs (e.g. Come-from-Beyond and jl777), but I think they need to write better specifications. I have personally told this to jl777.

What you have above is very incomplete.

At this time, I am trying to figure out which group I should be working with.

I have respect for some (former and active) Nxt devs (e.g. Come-from-Beyond and jl777), but I think they need to write better specifications. I have personally told this to jl777.

What you have above is very incomplete.

At this time, I am trying to figure out which group I should be working with.

    This update adds the Prunable Tagged Data feature, planned to be enabled at the voting system block too.
    Prunable tagged data are similar to prunable plain messages with no recipient, but with additional searchable metadata fields added. This feature can be used for decentralized and trustless distribution of small (up to 42k, including the metadata) pieces of data, which are by default stored for two weeks only (24h on testnet), but can optionally be stored longer or indefinitely by some nodes, and can be verified against the blockchain even after their expiration.
    Currently each tagged data can have the following fields, in addition to the data itself: name (required), description, tags, type, isText, filename.
    Name, description and tags are indexed and searchable using Lucene. All data and metadata is prunable, after pruning only a single 32 byte hash remains.
    Fee for either uploading or extending tagged data is based on the total data size (including metadata), and is 1 NXT for up to 1k bytes, 0.1 NXT for each 1k above, up to the limit of 42k.

New APIs:

    UploadTaggedData - create and broadcast new tagged data.
    ExtendTaggedData - extend the expiration time of already uploaded tagged data. If the data is still available, only the transaction id is needed. If not, already pruned data can be resurrected by including (in addition to the original transaction id) all of its fields too, i.e. name, description, etc. Anyone can submit an extension, not only the original uploader. Each extend transaction increases the expiration deadline by two weeks (24 h on testnet). Extending an existing tagged data from another account does not change the original submitter account id by which it is indexed and searchable.
    VerifyTaggedData - used to verify expired tagged data downloaded from another node, against the hash in the current blockchain.
    SearchTaggedData - full text search on name, tags, and description, optionally filtered by submitter account.
    GetTaggedData - retrieve tagged data by transaction id.
    GetAccountTaggedData - retrieve all tagged data submitted by a given account.
    GetAllTaggedData - retrieve all existing tagged data.
    GetDataTags - returns the distinct tags of all tagged data, with the number of data having each tag.
    GetDataTagsLike - prefix search of data tags.
    GetDataTagCount - the total number of distinct tags.
    All the Get* and Search* APIs above can only retrieve tagged data that has not been pruned yet.
Currently the pruning of tagged data is controlled by the same configuration properties that are used for prunable messages expiration.
Same as with prunable messages, when using broadcastTransaction API to submit an already signed tagged data upload transaction, the prunable parts must be in the prunableAttachmentJSON parameter in case transactionBytes parameter is used. If submitting transactionJSON, it already has the prunable parts.

More info here :
https://www.linkedin.com/pulse/why-nxt-great-2-data-cloud-bas-wisselink?forceNoSplash=true