The Data In The Open - dito! A privately sharing p2p system distributing its data always encrypted for specific group/s
+ Your Comments
logo.jpg
+ More&Related...

Under Humanitarian Agpl License, an element of the privateQ project

A privately sharing p2p system distributing its data always encrypted for specific group/s, running its applications only locally and storing its redundant data in some cheap storage, cloud or elsewhere:

dito.jpg

The Data In The Open (dito): is data structured in files, each is encrypted for groups of readers (gpg —group ), where the data is in the open (i.e. shared in public boxes/folders/drives/url) and each of its files is renamed and located by any field of its locator, being a record in the (originally named) locators.csv encrypted file

  • being specific per root and additionally held by each of the participants (involved peer), while
  • being synced/refreshed/notified upon its cid changes, where
  • each of its locator records is defined such that
    • nid (as in node id) is of 64 char of 32 digit pairs coded in base32 for index<1024 per each layer<31, as the last pair indicates the node's version;
    • cid (as in content id) equals hash(content), optionally with some hashcash;
    • name(data)=cid(data).type(data), as its original name is moved to its locator (for revalidating in the open as being unchanged and matching content by type from the node until its root);
      • stand(data)=(nid(data), name(data));
      • h(data) is the host function to download or upload the data, eg. link to dedicated 5G on transfer.sh and how to get it public also on gdrive; and
      • locator(data) =(nid(data), cid(data), type(data), cid(stand(data)), original-name(data), age(data), max(age), h(data), list of signatures upon cid(stand(data))).

News:

  • using it under humanitarian agpl, while encrypting for group, ie symmetric key of document is encrypted asymmetrically with each of the pub key of the group's members, with interface such as in gpg4usb on Signal Protocol (what is the lib or class to be use in qt environment?),
    • such that those groups are nested into each other and represented in a tree by their node name prefixing the name of that group and then using it for dito
      • such that the encrypted for group document is hashed and then named and then referable by the hash value, for creating something like blockchain visible only to that specific group, where the individuals are referable by iiaom not email, name tel number, andorid app etc.

Notes:

  • At the same node's version, if not defined elsewhere, there could be more than one file of different name.type , original names , age , max(age) or signatures.
  • By inserting into the content of file the name.type of its origin and allowing only one such name.type per each node's version, history is maintained without being rewritten.
  • This should be used by 2 separated applications (preferably on an external device):
    • online-app: Only for get offline after fire offline-app after get online then download, upload or move, i.e. download then upload by tor, torrent or any browser.
    • offline-app: fired after download: decrypt/verify ,view , modify encrypt/sign, fire aonline-app (upload this)
Screenshot%20-%2003072016%20-%2006%3A12%3A13%20PM.png

Dito use case: Assuming anonymous can only download or add files only to area under digesting dito node, such that the file is to be automatically removed when does not comply with specific conditions to be checked in specific period of time (such as per cycle, it must be younger than max age or permitted by…), such that when accepted the file can be moved to specific participant/s (optionally mapped to iiaom) to be sitting in the corresponding dito-node, where one or more of the participants is functioning as dito-gate-keepers optionally peeking data from the pool before it's expired.

  • This, after acceptance by the dito-gate-keepers, can be stored additionally to log of distributed records (in messages and/or files), as dito tree of db»table»column»sorted-field, where each node has name, type and description including how to use it.
  • For to reduce spamming risk, the node owners can specify excepted formats up-to max size, lifetime etc and other conditions, with iiaom and public key etc.

The evolutionary naming in dito LogChain: being a p2p and communal bookkeeping of transactions and/or sharing information eg music, while using, instead of mining, signatures and optionally iiaom of authenticators. where

  • authenticators are or representing those who made the transactions or bring the information and
  • the cid(stand(data)) is digitally signed by, and optionally with the iiaom of, authenticators granting the missing coherence, which is missing from the regularly made activity to be by most of the peers, such as matching hashes of the origin until root, or checking balances/resources against statements etc.

Conclusion The data, being separated from its meta and named somehow, is encrypted (with id of its senders ,its expiration-date,its name,its type,its msg) for specific recipients and stored temporally and hence its url is separately given in another channel to the recipients. Using, publicly or privately, services like https://transfer.sh/ + curl to (up/down) load and https://otr.im/clients.html to notify formated records, where the dito app does:
0. id is iiaom or fingerprint and optionally iiaom, instead of email, is set to key-id, as the app has id mapped (valued) by nice gui identity (key) able be recognized by the user
1. sender, it=encr4ids(file=(from ,, expiration-date,name,type ,, msg))
2. sender, what =url(upload(it))
3. sender, notify: record line formated as: to ,, what, in room or privately
4. recipient, download
5. participants being senders and recipients, optionally log history keeping their record lines
6. participants, periodically and optionally, share (using 1-4 steps) the hashed log to check for matching their own, which on successes produce one consensus with its measurement of that consensus to be marked on their own log.

Conclusion: Per each time-block consisting data and its locator, the longer the chain is, the harder the forgery in it, the maturer it's. The locator in size is small and in its name encapsulates, when conformation is reliable, the whole chain of blocks from the root until the current. When the conformation by peer/authenticators is given for the matching of the contents to their (hashed) names, it is given for the order from the root of the blocks with their timestamps or the match in of balance and movements and is not given for whether the data or its metadata tells true or not, only conforming the telling itself.

By Erez Elul @namzezam comcomist; This is given to anyone only under the humanitarian agpl license.
By pilepile, on 07 Mar 2016 17:09 history Tags:

comcomized-logo.png

~~Page's End!~~ Ignore ads by installing ublock.

page revision: 33, last edited: 15 Dec 2016 14:18
Edit Tags Discuss (0) History Files Print Site tools + Options
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License