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:

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)

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 pile

Expressions, information, interpretations and conclusions in non perfect and non projective but productive liquid unions channels !

This "dream" is for those who believe that the mainstream media, as it is held by interest groups, can only project but not produce relevant information, where the data is deleted after being processed:

• correspondents capturing data and then
  • 1. encrypting while compressing (7z) and sending it to temporal storage (dropcanvas dropbox ) and then
  • 2. sending its key, link and metadata encrypted with public key of/to liquid union channels of which
• editors editing it ( on station: being a rent-able editors room (in suitcase) ), rendering (rentrender frameserving) it and distribution on social and other media
  • (in delay of 1/2 hour, or so, for reducing real time vulnerability issues, remember occupy? why? 1, to keep the issue of privacy in control.2. to produce higher quality material).

The "dream" is having editing rooms getting encrypted or webrtc materiel and prepossessing it to feet the specific media, while the room are channels in liquid union and as such are financed proportionally to number of people in the groups assigning to it periodically, where the groups are of migrants in europ!

This is a call for establishing a co-working group realizing that "dream", where the co-working is by signing on the comcomized agreement https://comcomized.com/term-and-conditions/ and the lisences is humanitarian one, such as the humanitarian agpl http://namzezam.wikidot.com/humanitarian-agpl-license

see also:

• textsecure
• mini lock
• the gurddian project
• secure drop
• globalleaks

by pile

by pile

The Worth is calculated per each day such that: Today=the date of today, per each tablename: Dif=LastDate-Today, pech each columunname: Ratio=Dif/CoinLifetime and per each row: Sum+=startValue*Ratio.

The data is stored in encrypted directory including this app in 2 db: the My_db and the Op_db, where

• the My_db is used by any member,
• the Op_db is used by one or more operators being members. (and hence when each member is also an operator, the app is a p2p app, when being operator is rotated between members the app is democratic, otherwise centric).

The Communication of threads between members is by asymmetric keys, where threads, per each message n in an otr conversation, are defined so that

• t[n]=(message[n],date,hash(t[n-1])),
• hash(t[n]) is indexed by public_key(sender) and
• t[0]=(id(receiver),date,x), where, as in hashcach K(hash(t[0]))==0,
• K is defined by number of bits to be examined and x is a random.

The triplepin is the unique id of the member, which is given only in community depended conditions, such as only after having some recommenders for the uniqueness and the form of meeting with the member and of the recommenders.
id(coin) is a unique&random int.

id(member)=hash(pic(member));Changeable + retrievable by triplepin(member)

Payer is the previous Owner of a coin.

• The owner in payment should first see the payer then type the triplepin by which the pic is retrieved, and only after the pic matches the payer, that pic should be hashed and used/compared as an id. Hence such protocol is based on a human recognition (and not on the one of machine).

Rand, used as a transaction id in the distributed log, is a unique and random number, which is used as a receipt. It is produced by the Payer distributing that record; So that in payment, when paying and after proving ownership, the payer sign the new owner's id with the payer's rand, to create her/his new distributed record(rans).

Rcoin's log protocol:

• Chain=(hash(ChianPrev),hash(RandPrev,Id(Owner)))
• hash(pic)==id(user)
• triplepin is a unique number used as a key for all such pic, making each pic able to be changed Not as in the biometric info!
• N is the number of hashes implemented on itself beginning in id(coin) and ending in Nhash , for creating a prove of continuity. So, having the id(coin) and
• N you can create the Nhash of the N, where Nhash(N) =hash(Nhash(N++)) .

The Prove of ownership by id(coin), where op has in CoinsId@op Rand equals
the Rand the owners pull from Log@op by her/his Wallet@My:

• the Rand or RandPrev has the id(coin) and the owner verifies the signature and produces both: the Chain and the hash(Id(Owner) of the ChianPrev, which is the Chain in RandPrev.

See also hashcomposition:a-seperated-key-for-hashed-picture
IIaOM.hpp

by pile

• t[n]=(message[n],date,hash(t[n-1])),
• hash(t[n]) is indexed by public_key(sender) and
• t[0]=(id(receiver),date,x), where, as in hashcach K(hash(t[0]))==0,
• K is defined by number of bits to be examined and x is a random.

by pile

by pile

• Each rectangle is hashed separately in the crop defined by its arguments;
• The composition is given separately (in a specific transaction) and all rectangles in their order define together the reference to the picture and reference could be hashed again for to be squeezed again to a predefined size (used as an id);
• Overlapping means hashing part of hidden rectangle with the shown one;
• Per each corner the shortest rectangle on wall defines the highest of all others;
• The first two zeros define the containing rectangle and each other zero define changing direction until the pair of zeros that define the end after which the next 2 pairs are of the original picture (first of the position of its top left corner and the second of itself) and then terminate.

eg: (0,0)(0,0)(45,400) is the non-overflowing composition of only the original being a square of which diagonal=400 pixels.

by pile