Compound Structures

From Adam Colton
Revision as of 22:28, 1 March 2016 by Adamcolton (talk | contribs) (Created page with "== Compound Structures == === Burnable Resource === Any resource can potentially include meta-data. A burnable resource includes a hash-digest. A burn notice can be issued id...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Compound Structures

Burnable Resource

Any resource can potentially include meta-data. A burnable resource includes a hash-digest. A burn notice can be issued identifying the resource and including the hash input that produces the digest.

This can be useful for managing file distribution. For instance, if I'm trying to get an email to someone, I can make it burnable, and include the burn code in the email. Now, when the intended recipient has a copy, they can issue a burn notice and anyone caching a copy, waiting for them to receive it can delete it so it doesn't take up space.

Braid

Two users that wish to communicate but remain anonymous can create a braid. Users can establish communication via a signal.

Alice sees that Bob has posted a signal and would like to open communication. She creates a few (say, 6) return routes, each with a limited number of uses (say 10). Bob can now send up to 60 messages to Alice. Bob uses one of these to send Alice a similar package. Alice knows the 18 nodes she used in her routes. When one of those nodes goes offline, she can send Bob a new route to replace it.

There will be a defined protocol for using the channels. Something that uses the channels mostly evenly, but in a way that there is always enough redundancy left over to patch cut lines. If Bob is not following protocol, Alice can cut the communication because he may be trying to locate her.

Virtual Server

A group of peers can form a virtual server. A server is defined by it's ability to store resource and perform computation.

The group can manage resource redundancy. Each resource will have enough copies to reasonably protect against loss, but no user needs to carry the entire server content.

Any user can perform a computation. But to reduce repetition, complex computations can be performed, signed and published. Particularly important here, if a user provides some input to the server, a few peers can validate it, then the rest of the group can use their validation. But each node needs to independently choose if it will perform a validation. If we were to just say ok - there's already 3 validations, that would make conspiracy easier. If, instead, each node makes the choice independently, than we may see an average of 5 validations, if we see 10 validations, that may be a sign of conspiracy, but as long as the conspirators don't control a significant portion of the nodes, it should be easy to root out.