ComComist
This project's aim is to build the infrastructure for a new concept claiming that the memebrs in any democratic organization must be equal (peer) owners over the assets/proprieties of the organization (owners as shareholders having equal number of shares). For more about it try Comcomize The Occupy Movements from http://alex11.wikidot.com/comcomize-the-occupy-movements , the 6 pints from http://is-with.wikidot.com/what-comcom-is-in-6-points, manual form http://is-with.wikidot.com or on facebook at http://fb.me/peer.owners
A call and specification for Developing Is the Developing is to be done for free? The product will be open, the product can be used for server , which then can have revenue and in this moment the programing time is not payed. we also make organization to define the market http://fwd4.me/01lz , when this will be more established , then investors would come in and programing will be payed. i believe that sooner getting in give advantage. the comcom-platforms in relation to some such stations.
| the Applications | |||||
|---|---|---|---|---|---|
| sdsp Secure Data Storage Protocol | p2g4p peer to group for peers - the communication is never directly between users and only user to group and group to all users | Regulators identity holding | board-meeting-app project tracking/issue E-democracy theory E-democracy practice | social-app | stock-exchange app |
| The licensing1 for the platform for comcomized units | ||
|---|---|---|
| of | at | under |
| specification | here and elsewhere | CC Attribution-NonCommercial-ShareAlike |
| application and code | github | agpl |
| the authorization that the code produce the intent application | the comcoms in the chain of the #G(global) #L(local) #P(provide) #U(use) | @A@ |
self-organized-regulator-systems2: This server/client application is designed to provide decentralized systems of identification and regulators adaptive to such of passport or alternative to those. Specification:
- Spec1: It is required for all kind of comcom's regulations to insure that via all layers of holding, no holder could have more than one potion -
- This is to be done by "trees of ownership" in which the owner is one child of the owned,
- where the one-who-invites is the connection between the owners and the owned,
- where the root of such tree is the sys registering the ownership form the most owned entities (as children of the sys) to the most owning being the people (as the leaves in the tree) and
- where each leave is associated with person identified by one unique "smart card autonomously" (see spec2).
- This is to be done by "trees of ownership" in which the owner is one child of the owned,
- Spec2: The "smart card autonomously" for unique identification of the owners:
- The card has its own processor able to identify only one bio-info, (bio-info such as fingerprint) readable and verifiable independently by the card. Becouse of reasone of price this actually should not be a card but a device able to connect coonector such as by usb to some box such pc or phone. the device then will consist of reader and something like Fingerprint Based On FPGA. or it can be on dongle connected to retinal scanner.
- It's processor knows only the hash key of the bio of one person only and the "data" available to other devices only when the card is on-line.
- Only after completing the interdependent identification the card will become "on-line" by writing data available for use with other devices, otherwise such data is deleted and the card is off-line, where being available is only for a define time and by double touching it become off-line again.
- The sys of registration issuing such cards holds only that hash key and issue the card only after verified case of "not found such hash" in all other such sys. Taking the bio in the event of issuing must be carefully done to prove the authenticity of the relation of the bio-info with the person.
- The card has its own processor able to identify only one bio-info, (bio-info such as fingerprint) readable and verifiable independently by the card. Becouse of reasone of price this actually should not be a card but a device able to connect coonector such as by usb to some box such pc or phone. the device then will consist of reader and something like Fingerprint Based On FPGA. or it can be on dongle connected to retinal scanner.
- Spec3: Each registered entity has one number "i"==("s","e","q"), where
- "s", is id of one such sys in use by other such sys
- "e", is id of one Entity registered in such sys
- "q" , is also a column name, in the table holding such id in such sys
- as "q" is a qualifier of the (registered) entity, which reflect one of the 3,
- when "q"=0 , the entity is person,
- when "q">0, "q "is the degree of being held and
- when is "q"<0, "q" is degree of authentication being authenticated by this sys (most near is -1 directly authenticated by this sys , as the ones authenticated by those of -1 are in -2 etc)
- Spec4: The authentication (by encrypted hashes) between such sys, where "A" authenticate "B" and per entity matching id registered in "B", is as following (see also this):
- the entity register on "A" itself with its ("e","q") and its name and in the same time (+- 10 minutes or so) "B" notify "A" that this is happening.
Notes:
- 1) The "s" should be calculated in base 2, such that
- when "s" is odd then it is identifying other such sys (self-organized-regulator-systems) and
- when "s" is even then it is identifying non comcom organizations , e.g. such as private company type ltd in london or so.
- 2) The "e" should be calculted in base 3, such that
- when remain =0 then the comcom is Scomcom
- when remain =1 then the comcom is Icomcom
- when remain =2 then the comcom is Dcomcom
- 3) “identity proof” of 5 elements: A) first name, B) last name, C) who invite, D) recognized authority issuing document of identity (such as Germany issuing the document being passport) and E) photo able to be identified as the one of the one from the document of identity.
- Having such “identity proof” of an holder been registered, requires that the holder already agreed to lose all holding registered in the system and in the systems collaborating with it, as it is found that per each such registered ComCom, the holder holds directly, or indirectly, more than one position.
- Hence the more valuable comcomS are registered in it the stronger is the proof the system can provide. (it might be useful to require reinforcement of the identity every 3 months).
- Having such “identity proof” of an holder been registered, requires that the holder already agreed to lose all holding registered in the system and in the systems collaborating with it, as it is found that per each such registered ComCom, the holder holds directly, or indirectly, more than one position.
- 4) On any authentication&login (including via p2g4p between u and g or client and server on sdp), check of id in respect to holding in all comcom in the system for having no id has more than position in each comcom.
- 5) This could also make one farther step in the concept of bitcoins (analogy to gold) - the step of Dcoins (digital coins, analogy to cogency per community of the sys, such community as a state), which
- instead of sending the chain-log to any, sending it only to the memebrs in the sys, and
- instead of printing moeny being sent only to individuals spending computing power, distributing the printed moeny proportionally to the held amount by each holder and to all the moeny holders. and amount of such moeny is
- valued in Dcoins and periodically, printing moeny or taking tax of (export-import) * factor.
P2G4P
p2g4p (peer to group for peers): anonymity (for the other but not for the sys) in 1st degree of communication, such that the id is "known" only to the regulating sys, where each message is sent only to the whole group and never between individuals in the sys. In p2g4p the id of the entity is either in sys (e,q) or out of sys (s,e,q). The q is used in the communication for letting the other communicating with the entity know at least the q and sys.
- P2G4P (peer to group for peers) messengering and hierarchies
- No Mail, but Yes Message
- N is G and/or U, where G==group, U==user, N ==node
- No U->U [for anonymity of U in G],but Yes U->(one or more)G->U [G only to all U(G) for transparency]
- on Message delivery failure (e.g. as U is offline)
- send "delivery failure notice" to the G(G), as the up most G are mirroring of the G below being server, (hence such server is lazy server, which is busy only on failures of the p2p and such hierarchy could also match the dept in holding), so that the G on the failure will send to all its U request to swap the offlined one.
- on Message delivery failure (e.g. as U is offline)
- The group has pubkey of each user and send to each user only encrypted by corresponding pub key. The group never has the plan msg stored - if stored then only encrypted by the pubkey. The user shake hands before sending to group . the group of children groups has all pubkey used by children groups.
- e.g.:
- monthly ticket: i ask my handy, where and when (now) is the nearest pack of tickets from which at least one is available to my destination and for how long then i can hold it and after holding where to put the ticket for reuse again ?
- in the same way share ride on rented car and rent your car for sharing etc.
- Spare Part of any thing car, fridge , washing machine etc
- recycle unused objects closes, food or any other objects et
- why comcom?
- because on big scale and with alternative competitive units and non mafia/big-commercialized organizations (which are hierarchic), how could we trust each other on this?
Comment removed.
Post preview:
Close preview