Commit 724f7f4db9d691f2dabb938371fd954eda5404c5
scaffold more content, mostly by quoting @dominic
Michael Williams committed on 11/7/2016, 3:48:37 AMParent: 777ef0c70cdad4edda1a0e620d1bccc1a1c56a29
Files changed
| README.md | changed |
| SUMMARY.md | changed |
| concepts/feed.md | changed |
| concepts/gossip.md | changed |
| concepts/identity.md | changed |
| concepts/index.md | changed |
| concepts/local.md | changed |
| concepts/private-message.md | changed |
| concepts/pub.md | changed |
| concepts/capability.md | added |
| concepts/stream.md | added |
| principles.md | added |
| README.md | ||
|---|---|---|
| @@ -26,11 +26,13 @@ | ||
| 26 | 26 … | ``` |
| 27 | 27 … | |
| 28 | 28 … | The `SUMMARY.md` is the manifest on which the compiled gitbook is based. Edit that if you want content in/out of the book. |
| 29 | 29 … | |
| 30 … | +> If you see a job that needs doing - that is your job. | |
| 31 … | + | |
| 30 | 32 … | ## Other Projects |
| 31 | 33 … | |
| 32 | -Scuttlebutt is not the only project working in a decentralised encrypted space. Here are a few other projects also working on solutions: | |
| 34 … | +Scuttlebutt is not the only project working in a decentralised space. Here are a few other projects also working on solutions: | |
| 33 | 35 … | |
| 34 | 36 … | - [Matrix](http://matrix.org/) |
| 35 | 37 … | - [Bitcoin](https://bitcoin.org/) |
| 36 | 38 … | - [Ethereum](https://www.ethereum.org/) |
| @@ -39,4 +41,9 @@ | ||
| 39 | 41 … | - [IPFS](https://ipfs.io/) |
| 40 | 42 … | - [Dat](http://datproject.org/) |
| 41 | 43 … | - [Solid](https://github.com/solid/solid) |
| 42 | 44 … | - [cjdns](https://github.com/cjdelisle/cjdns) |
| 45 … | +- [Syncthing](https://syncthing.net/) | |
| 46 … | +- [Indie](https://ind.ie/) | |
| 47 … | +- [Twister](http://twister.net.co/) | |
| 48 … | +- [WebTorrent](https://webtorrent.io/) | |
| 49 … | +- [StrongLink](https://github.com/btrask/stronglink) | |
| SUMMARY.md | ||
|---|---|---|
| @@ -1,15 +1,18 @@ | ||
| 1 | 1 … | * [Introduction](README.md) |
| 2 | 2 … | * [Applications](applications.md) |
| 3 … | +* [Principles](principles.md) | |
| 3 | 4 … | * [Stories](stories/index.md) |
| 4 | 5 … | - [Gossiping Securely is the new Email](stories/gossiping-securely-is-the-new-email.md) |
| 5 | 6 … | * [Modules](modules.md) |
| 6 | 7 … | * [Concepts](concepts/index.md) |
| 7 | 8 … | - [Identity](concepts/identity.md) |
| 8 | 9 … | - [Feed](concepts/feed.md) |
| 9 | 10 … | - [Message](concepts/message.md) |
| 10 | 11 … | - [Private Message](concepts/private-message.md) |
| 12 … | + - [Gossip](concepts/gossip.md) | |
| 13 … | + - [Stream](concepts/stream.md) | |
| 11 | 14 … | - [Link](concepts/link.md) |
| 12 | - - [Gossip](concepts/gossip.md) | |
| 13 | 15 … | - [Local](concepts/local.md) |
| 14 | 16 … | - [Pub](concepts/pub.md) |
| 15 | 17 … | - [Blob](concepts/blob.md) |
| 18 … | + - [Capability](concepts/capability.md) | |
| concepts/feed.md | ||
|---|---|---|
| @@ -2,4 +2,54 @@ | ||
| 2 | 2 … | |
| 3 | 3 … | A feed is a signed append-only sequence of messages. Each identity has exactly one feed. |
| 4 | 4 … | |
| 5 | 5 … | Note that append-only means you cannot delete an existing message, or change your history. This is enforced by a per-feed blockchain. This is to ensure the entire network converges on the same state. |
| 6 … | + | |
| 7 … | +## Is Scuttlebutt a Blockchain? | |
| 8 … | + | |
| 9 … | +> The main difference is that ssb does not use Proof of Work to choose the next valid block for a global blockchain. Instead, each identity gets their own personal blockchain (i will use "sigchain"). So bitcoin is 1 blockchain, ssb is many sigchains. | |
| 10 … | +> | |
| 11 … | +> The following will be true of pretty much any secure decentralized system: | |
| 12 … | +> | |
| 13 … | +> Both use hashes as links to build structures. bitcoin and ssb are both based around chain structures. ssb also use links to create trees (eg, discussion threads) | |
| 14 … | +> | |
| 15 … | +> Both use signatures to represent an actions performed by an identity, and public keys to represent that identity. | |
| 16 … | + | |
| 17 … | +- %o7qQdE9/NKbNuy1anZIoOWrnsfFF3Cef7ozZwrNcRdQ=.sha256 | |
| 18 … | + | |
| 19 … | +> It mainly differs in philosophy. secure-scuttlebutt avoids not just centralization, but also global singletons. So there is no DHT. | |
| 20 … | +> Both are built on the concepts of hashes as links and public keys as identity. | |
| 21 … | +> | |
| 22 … | +> Then the main structure in ssb is that each user's feed is an append-only signed chain. This structure is very simple, and optimized for efficient replication. To get all you latest updates, I just have to tell a mutual friend the latest sequence number I have received from you. | |
| 23 … | +(on ipfs, i'd have to work backwards from your latest ipns value) | |
| 24 … | +I think a forward replicating database is easier to reason about and build other things on top of. | |
| 25 … | +> | |
| 26 … | +> Since there is no global network, everything depends on your social network. That is the gamble here. But, I think it's a good one. Life has confusingly many options - but we have a simple solution, ask your friends. Spam filtration is the same thing from the other end, what do i not want to see. Take things like the search on google play store - it's so fully of crap (and full of spam reviews) that you are better off asking on twitter. I call twitter solicited spam. since it's pull only, it just doesn't have the same spam problems as email (except for mentions/replies/favs) | |
| 27 … | +> | |
| 28 … | +> By default, you replicate the feeds you directly follow, and the feeds they follow. this provides availability for the network, and also means you can see replies from someone you don't directly follow. it creates a soft boundry to your social network, so once we scale, you won't get spam in your mentions, etc. | |
| 29 … | + | |
| 30 … | +- %XnwMywLJAWqRXCAt9YmPuIghlr9tyAZNiKgbDOg385g=.sha256 | |
| 31 … | + | |
| 32 … | +## [Non-repudation](https://en.wikipedia.org/wiki/Non-repudiation) | |
| 33 … | + | |
| 34 … | +> With a signature chain, you'd still have that even if it where possible to "forget" parts, because someone probably has that post, and they'd be able to come forward, and everyone could verify that was the deleted post. | |
| 35 … | +> | |
| 36 … | +> Having peruasive non-repudation also means that you can't claim someone said something they didn't, so you can't post a doctored screenshot because no one will believe it. | |
| 37 … | + | |
| 38 … | +- %ZmudAToEvD6baAFDkrUjj28ySXhI7CRGWRvuYLwMmtQ=.sha256 | |
| 39 … | + | |
| 40 … | +> @johnny that is true. You could abandon your account, throw your hands up and claim "i've been hacked!!!" that might be a bit harder to pull off credibly (depending on exactly what you where trying to delete) | |
| 41 … | +> | |
| 42 … | +> But I have a more radical idea, I'm not sure if the world is ready for it, but here it is: you could apologise. Then the bad post would show back links to the apology, and readers could interpret it in the new context. | |
| 43 … | + | |
| 44 … | +- %xwlk7+jk+jTLvaTq/0G8T5YaoXTacM7Gb7Ko8xVUtuY=.sha256 | |
| 45 … | + | |
| 46 … | +## Consistency | |
| 47 … | + | |
| 48 … | +> I hate to rain on a parade, but one thing is that the relationship between boats is a lot more libertarian than the relationship between the crew of one boat. Even Plato uses the example of the ship at sea to argue for his idea of the geek dictator ("philosopher king"). | |
| 49 … | +The crew are literally "all in the same boat" and so there isn't really much room for disagreement. Historically, western culture has decided that the best way to run a boat is under the command of a single captian, and not many people have argued with this. I wouldn't be surprised if it's impossible to ensure the boat without a designated captian. I think this will create a tension that you'll have to work around, at least. | |
| 50 … | +> | |
| 51 … | +> On the other hand, if this was a flotilla of boats... then I think you'd begin to see a natural harmony between you idea and decentralization. Islands of consistency in a sea of eventualness. | |
| 52 … | +> | |
| 53 … | +> Prehaps, you could pitch this not as a single vessel, but as a prototype for a flotilla... maybe invite current sea captians to join your network? That way you might be able to release some of the inevitable pressure of forcing participants into too small a space (1 ship) | |
| 54 … | + | |
| 55 … | +- %2vsznn20SD82ChXVcMKKt4J2/Cjcle1pjMFI+bpYjkM=.sha256 | |
| concepts/gossip.md | ||
|---|---|---|
| @@ -17,8 +17,41 @@ | ||
| 17 | 17 … | Since feeds are append-only, gossip is simple: request all messages in the feed that are newer than the latest message you know about. Scuttlebot maintains a table of known peers, which it cycles through, asking for updates for all followed feeds. |
| 18 | 18 … | |
| 19 | 19 … | Since the messages are always signed, information can be distributed in any way, such as through a [sneakernet](https://en.wikipedia.org/wiki/Sneakernet). For example, you could put the latest gossip on an SD card and send it to your friend via [pigeon post](https://en.wikipedia.org/wiki/Pigeon_post). |
| 20 | 20 … | |
| 21 … | +> ssb is persisted without you going out of your way, it may be hang off of you for ever, but it's not a burden on you, you don't need to do anything to maintain that, except to continue being friends with people. | |
| 22 … | + | |
| 23 … | +- %Cd6YRARJX29mkaP798JII3WwmlOWXEs6v8p1GjsSZL8=.sha256 | |
| 24 … | + | |
| 25 … | +> You could argue that ssb is a pub/sub protocol. | |
| 26 … | +> Bandwidth may be important, but it's not gonna be the architectural deal breaker that latency will be. We've got at least 10 years to go before we'll need it, so the pitch would be more around developing a body of expertise in replication oriented software. | |
| 27 … | + | |
| 28 … | +- %fr1H5OP4C6SRoZ3yNyJz02lh2fwR9DLH97hksYh+Op8=.sha256 | |
| 29 … | + | |
| 30 … | +> That was on the call that I missed. | |
| 31 … | +> If I had been there, I would have pointed out two things: | |
| 32 … | +> | |
| 33 … | +> the ipfs model works best if the blobs are popular - you have to connect to peers which also want them, not really the long tail though, | |
| 34 … | +> | |
| 35 … | +> And it also doesn't provide much privacy. You have to advertise which blobs you have on a DHT, accessible to everyone, so you'll never have very good privacy about which blobs you have. | |
| 36 … | +> | |
| 37 … | +> Where as, by gossiping the blobs, you'll get some extras, and you can plausably claim "I was just holding this for a friend" | |
| 38 … | + | |
| 39 … | +- %Ooe/pswWabTDRm8gg+t5jfHzYzYUq/QHCRSnPtWelqg=.sha256 | |
| 40 … | + | |
| 41 … | +> the real problem is a bit more detailed than that. Even if you could easily address any device, that doesn't mean you could host a website on your phone. well, you could, sure, but that would just mean you have to keep your phone constantly on and connected. | |
| 42 … | +> | |
| 43 … | +> The more important thing about applications like ssb and ipfs etc, is that they may operate "offline" you connect address and connect to the data, not the device. | |
| 44 … | +> | |
| 45 … | +> The device is temporary and the data is not. That is completely the other way around from traditional systems. It helps here to remember just how modern crypto is. Modern Cryptography (hashes + signatures) is less than half as old as computer science. MC was only invented in the late 70's, but computer science was invented in the 30s (turing machines, etc) | |
| 46 … | +> | |
| 47 … | +> The internet existed before crypto, and so did unix. | |
| 48 … | +We are only just figuring out how to build things with crypto... | |
| 49 … | +Addressability is the easy part. we want to be able to publish from your phone, but we don't actually want everyone in the world to be connecting to it, that would just DDOS your phone. With the web, your post goes viral, that is a DDoS, but with a correctly designed P2P network, when your post goes viral it just works better. | |
| 50 … | + | |
| 51 … | +- %R3FPwcmwWhIra/iTWyctKderB7rcQ5BVNosOtsaf7Z4=.sha256 | |
| 52 … | + | |
| 53 … | + | |
| 21 | 54 … | ## Network |
| 22 | 55 … | |
| 23 | 56 … | The protocol creates a [global gossip network](https://en.wikipedia.org/wiki/Gossip_protocol). This means that information is able to distribute across multiple machines, without requiring direct connections between them. |
| 24 | 57 … | |
| @@ -28,4 +61,45 @@ | ||
| 28 | 61 … | |
| 29 | 62 … |  |
| 30 | 63 … | |
| 31 | 64 … | This is because gossip creates "transitive" connections between computers. Dan's messages travel through Carla and the Pub to reach Alice, and visa-versa. |
| 65 … | + | |
| 66 … | +> You don't need all the data on your computer, just the data that is for your network, people you know, and maybe people they know. | |
| 67 … | +> | |
| 68 … | +> The idea is not to have the entire network, just a subset of it. | |
| 69 … | + | |
| 70 … | +- %s8ISugQl8XLm09u4w1ZZi1yocWkvxycmTBA4okPPWc8=.sha256 | |
| 71 … | + | |
| 72 … | +## Blocking | |
| 73 … | + | |
| 74 … | +> yes! so we have a blocking feature in scuttlebot, but it's really more like twitter block, which ensures that they never get your feed. I think having both of these is best. | |
| 75 … | +> | |
| 76 … | +> You can't remove all evidence that you ever knew that feed, because it will still be in the log, but you can post a message saying that feed is blocked, and then refuse to replicate new messages from them. | |
| 77 … | +> | |
| 78 … | +> we have also talked about having subscribable block lists, which would be appropiate in this case! | |
| 79 … | + | |
| 80 … | +- %1g2HIV449C3xGSIc5rxaptoWa7pvK7oLVdpCa1nuq8c=.sha256 | |
| 81 … | + | |
| 82 … | +> then you unfollow them. and/or you post a special message warning others, and then their software doesn't apply the friend-of-friend rule for that feed. | |
| 83 … | +> | |
| 84 … | +> But to be honest, we havn't had many assholes join (just one, but he left again), so we havn't had to really implement moderation controls yet. | |
| 85 … | +We can't have centralized moderation, which is necessarily one-size-fits-all and doomed to privledge some over others anyway, but instead we can create tools so that a given community can moderate it self. | |
| 86 … | +> | |
| 87 … | +> for example, if you can block or mute someone, you could also subscribe to someone else's moderation. maybe to protect a more at-risk member - say you'll automatically block anyone they block gives them power. | |
| 88 … | +> | |
| 89 … | +> We can't make a system that assholes can't use, but we can make one where you don't have to listen to them. If push-based systems give you freedom of speach, this is freedom of listening. | |
| 90 … | + | |
| 91 … | +- %jGdw9P7MVsl2TLSUkXfHhubsMeBvEz0hGl7zNCdo8jg=.sha256 | |
| 92 … | + | |
| 93 … | +## Spam | |
| 94 … | + | |
| 95 … | +> All the defences against sybil attacks basically boil down to making it "too expensive" to create a sybil swarm. Basically, finding some way to create a "real cost" to creating an identity in the system. | |
| 96 … | +> Bitcoin does this with proof of work, because processors & electricity are expensive. Ethereum enables you to do this with money. Often, centralized services require you to confirm your phone number (using the price of simcards). | |
| 97 … | +> | |
| 98 … | +> The other method is to do some kind of network analysis. This is broadly the approach that ssb uses - here independent parties post "follow" messages which bring that peer into your network. https://www.stellar.org/ is anothe example of this approach. | |
| 99 … | +> For a voting system, you could have each peer state who they accept the votes of, and discount peers that are not strongly connected to yourself. This is based on the assumption that it would be difficult to for an attacker to trick many people into expressing "trust" in them. This would require people being educated to take that expression fairly seriously, though. | |
| 100 … | +> | |
| 101 … | +> Maybe, if a sybil swarm did sneak in, and made a reckless proposal, the rest could sever their network from those sybils - just succeed. | |
| 102 … | +> | |
| 103 … | +> Of course, all of these approaches should probably be considered unproven... | |
| 104 … | + | |
| 105 … | +- %oDcN+0dus8WD7J985vjOmewyftoIN9/8j2GrtG3Guck=.sha256 | |
| concepts/identity.md | ||
|---|---|---|
| @@ -1,5 +1,60 @@ | ||
| 1 | 1 … | # Identity |
| 2 | 2 … | |
| 3 | -An identity is simply a [ed25519 key pair](http://ed25519.cr.yp.to/). The public key is used as the identifier. | |
| 3 … | +Your identity is "who you are". | |
| 4 | 4 … | |
| 5 … | +## True Name | |
| 6 … | + | |
| 7 … | +In Scuttlebutt, your [True Name](http://dominictarr.com/post/106497926352/asymmetric-cryptography-works-like-magic) is represented as an [ed25519 key pair](http://ed25519.cr.yp.to/) using [libsodium](https://github.com/jedisct1/libsodium) ([why?](http://dominictarr.com/post/133109715357/which-js-crypto-library-should-i-use)). | |
| 8 … | + | |
| 9 … | +The private key is your secret not to be shared with anyone. The public key is used as your identifier. | |
| 10 … | + | |
| 5 | 11 … | There is no worldwide store of identities. Users must exchange pubkeys, either by publishing them on their feeds, or out-of-band. |
| 12 … | + | |
| 13 … | + | |
| 14 … | +> There is no session, and no logon. your identity is represented by a private key that is stored in on your computer. | |
| 15 … | +> | |
| 16 … | +> In ordinary websites, the server is the guardian of your identity, | |
| 17 … | +> and grants it to you. This is the reverse, you are your own guardian. | |
| 18 … | +> | |
| 19 … | +> When you make a post, it creates a signed record, that appends to a history of things you have done. When my computer sees your messages, | |
| 20 … | +> | |
| 21 … | +> it knows it's, well, actually it doesn't know who you are, but it knows you are the same identity as before. | |
| 22 … | + | |
| 23 … | +- %ox29TwlaATzXebEwpmzenTQKD2XN2cBrihCsHNm6qKE=.sha256 | |
| 24 … | + | |
| 25 … | +> So in the future, how i figure it will work, is when a child is born, the parents generate a private key for it. The parents could easily know the private key... and maybe that is for the best. But later, when the child is mature enough to understand the consequences, they would generate their own private key. Now they are cryptographically an adult. | |
| 26 … | + | |
| 27 … | +- %9M3KSMrxigeIxJDIdVgm9HmBL7dg71eHMVnGYwDbByI=.sha256 | |
| 28 … | + | |
| 29 … | +## Nick Names | |
| 30 … | + | |
| 31 … | +In Scuttlebutt, anyone can set a nickname (petname) for another peer. It's akin to a human-memorable symlink to a cryptographic identifier. | |
| 32 … | + | |
| 33 … | +> The web you are familiar with is organized like a property system. If you can claim a username, you "own" it. not here. here, you name is whatever people call you. | |
| 34 … | +> You can suggest a name, and an avatar, and we can use it. and you can rename us. This may seem unfamiliar at this point in history, but it is the natural way of the world. | |
| 35 … | + | |
| 36 … | +- %1H99noUzO+kUrj8zwX0stfuUvX29X8HgXjHErfnwkOY=.sha256 | |
| 37 … | + | |
| 38 … | +> In a centralized system, the database is the source of all truth and enforcer of rules. Enforcing a rule like "all names must be unique!" is easy. | |
| 39 … | +> | |
| 40 … | +> In a decentralized system, like ssb, there is no single source of truth. peers must enforce a rule with collective action. This makes for a _lot_ more wiggle room. To put it in database terms, it means anyone can write anything, but other clients will ignore what they think is invalid. | |
| 41 … | +> | |
| 42 … | +> So, names is patchwork are somewhat like IRC, except that when I mention you @akkartik it records both your human name and your public key, then I sign this message, so there is a cryptographic record that I call `@1DfC2qFuXuli/HOg3kJbKwxiOpc3jXLdJD3TnhtzWNs=.ed25519` "akkartik" | |
| 43 … | +> | |
| 44 … | +> I can call you anything. Unlike IRC, but like "real life", other people choose your name. So, in ssb, a _name_ is just a mapping from a string to a cryptographic token (i.e. public key, and git-ssb repos also have names) | |
| 45 … | +> | |
| 46 … | +> If I start using a new name for you, my old messages will still bear the name I used then, but it would still link to your public key. | |
| 47 … | + | |
| 48 … | +- %7hcvpITRduLDNKpLqN6Xm+8d/t7aQu2YqZhBO3CtSC0=.sha256 | |
| 49 … | + | |
| 50 … | +> Don't ask anyone's _opinion_ on a name, that is just a bikeshed, get people to use it and see what they _call_ it. Let names emerge, like winning at charades. | |
| 51 … | + | |
| 52 … | +- %am/DGQpKliHYgsYgUUXk4UHwz9rgn+0WN4oc4yq97Mw=.sha256 | |
| 53 … | + | |
| 54 … | +## Groups | |
| 55 … | + | |
| 56 … | +> To summarize, our ideas are that a group, by definition has an inside and an outside, and they also may have internal behaviour and external behaviour. Internal behaviour means it's possible to communicate privately with other members, external behaviour means it's possible for the group to speak/act as one. I want it to be possible to follow a group like you would follow an individual, ideally without needing the ssb to treat it differently (that depends on the right crypto though) | |
| 57 … | +> | |
| 58 … | +> this thread has a [good summary of our group ideas](%HRmMuXxv+4SzJkXVs+oy5K3PnEEi1kP8NOkID7auywc=.sha256) | |
| 59 … | + | |
| 60 … | +- %b8/CYP0xj+fXgB2u5eDOQUbBCqyJ+sXv/CvuZNDOVVA=.sha256 | |
| concepts/index.md | ||
|---|---|---|
| @@ -1,6 +1,45 @@ | ||
| 1 | 1 … | # Concepts |
| 2 | 2 … | |
| 3 | 3 … | This section is a collection of concepts that are useful to understand the scuttleverse. |
| 4 | -A lot of these are common to many of the current p2p database protocols. | |
| 5 | 4 … | |
| 5 … | +A lot of these are common to many of the current p2p database protocols, however there are important differences to keep in mind. | |
| 6 | 6 … | |
| 7 … | +## Network Topology | |
| 8 … | + | |
| 9 … | +> twitter implements a social network (decentralized network of friends and influencers) on a computer network with a different topology (data center hub and user spokes) | |
| 10 … | +> | |
| 11 … | +> Twister implement a social network (again, dexnet of friends & followors) on a uniformly distributed decentralized network, user feeds distributed across a DHT (distributed hash table) and a blockchain (for user names) - twister is decentralized, but it's uniformly decentralized, each peer puts in roughly the same commitment of resources, which sounds like a good thing, sure. | |
| 12 … | +But this means that twister is a decentralized implementation of a centralized idea, and thus conceputallly centralized. | |
| 13 … | +> | |
| 14 … | +> But secure-scuttlebutt is different, it maps a the social network on to a computer network that is essentially the same topology! that is, the connections between humans maps approximately to the the connections between computers. if you follow someone, you really actually follow them at the data layer. | |
| 15 … | +> | |
| 16 … | +> I feel this means the user experience is in harmony with the architecture of the system. | |
| 17 … | +> | |
| 18 … | +> I can't fairly claim that ssb isn't conceputally centralized right now, because there is only a small number of developers, but there is nothing in the architecture that prevents having many implementations - so if we succeed, I think that will happen. | |
| 19 … | + | |
| 20 … | +- %lmELhGVLXcWrygyG0whgkzkmjlmiB1jZf5EshQ5zfhs=.sha256 | |
| 21 … | + | |
| 22 … | +> bittorrent/DAT like protocols are pretty good for moving heavy data. (video, OS images, etc) the best part is that you collaborate only with other peers who are invested in a particular dataset. | |
| 23 … | +> | |
| 24 … | +> But the weakness (in my opinion) is that they rely on a DHT. | |
| 25 … | +> DHTs are bad because peers collaborate anonymously, you have cannot estimate their trustworthyness and consequently, DHTs tend to have poor privacy (because an adversary could easily add peers that monitor you) and poor sybil resistance (again, because you have no way to know that a peer is "near you" or "on your side") | |
| 26 … | +> | |
| 27 … | +> This happens because work is distributed between peers uniformly. | |
| 28 … | +> Peers are mapped into a hash ring, so to get a hash, you traverse peers closer and closer to your target. | |
| 29 … | +> | |
| 30 … | +> One of the core ideas in ssb is to map the computer network along the social network (thus defeating spam, because you arn't friends with spammers) | |
| 31 … | + | |
| 32 … | +- %0asWjhFa51ri/OOSXJgC/aUweNzhxHi2/7+PXhwUzH8=.sha256 | |
| 33 … | + | |
| 34 … | +## Permissions | |
| 35 … | + | |
| 36 … | +> secure-scuttlebutt absolutely aims to grow into a pretty good decentralized database, | |
| 37 … | +> but because it's _decentralized_ that means it's gonna turn out pretty different to say, mysql. | |
| 38 … | +> | |
| 39 … | +> The fundamental difference being that in a decentralized database, "permissions" are enforced by the reader, not the writer (or rather, receiver of the write - "the database") | |
| 40 … | + | |
| 41 … | +- %qn9zPU/d8021Cpv5/t7FFZv8eoUUDDOJ8xdhor5w+bA=.sha256 | |
| 42 … | + | |
| 43 … | +> This is the thing which is fundamentally different with this decentralized architecture than with centralized. In a centralized database, the database is the point of control. Who has permission to write what is determined by the database. In this decentralized architecture, if you want to write something, just write it. the other clients will decide whether that write was valid, and accept or ignore it. | |
| 44 … | + | |
| 45 … | +- %KSSrusb3gQsRe6d3ZkKfiQTrGWM7OB1ePNEh6yzsA8I=.sha256 | |
| concepts/local.md | ||
|---|---|---|
| @@ -1,3 +1,19 @@ | ||
| 1 | -# local | |
| 1 … | +# Local | |
| 2 | 2 … | |
| 3 | -SSB is hostless: each computer installs the same copy of software and has equal rights in the network. Devices discover each other over the LAN with multicast UDP and sync automatically. | |
| 3 … | +## Subjective | |
| 4 … | + | |
| 5 … | +Scuttlebutt embraces subjectivity. You are your own central authority on truth. | |
| 6 … | + | |
| 7 … | +There is no "objective" truth, no global singleton, no consensus process. | |
| 8 … | + | |
| 9 … | +Each peer can publish whatever they want, and interpret another message however they want. The meaning is created when two peers have the same interpretation. You don't get to choose how someone interprets you, but you may choose how you interpret them. | |
| 10 … | + | |
| 11 … | +## Hostless | |
| 12 … | + | |
| 13 … | +Scuttlebutt is hostless: each computer installs the same copy of software and has equal rights in the network. | |
| 14 … | + | |
| 15 … | +While there are [public peer servers](./pub.html), they are identical to the client peers rather than a special role. We feel that this doesn't make it not a peer to peer protocol, since anyone can run them, and your identity is not tied to them as in `email@domain`. | |
| 16 … | + | |
| 17 … | +## Local-Area Networks | |
| 18 … | + | |
| 19 … | +Devices discover each other over the LAN with multicast UDP and sync automatically. | |
| concepts/private-message.md | ||
|---|---|---|
| @@ -2,4 +2,9 @@ | ||
| 2 | 2 … | |
| 3 | 3 … | For private sharing, Scuttlebot uses [libsodium](http://doc.libsodium.org/) to encrypt confidential log-entries. Feed IDs are public keys, and so once two feeds are mutually following each other, they can exchange confidential data freely. |
| 4 | 4 … | |
| 5 | 5 … | Private-box is a format for encrypting a private message to many parties. It is designed according to the [audit-driven crypto design process](https://github.com/crypto-browserify/crypto-browserify/issues/128). You can find the repository on at [github:dominictarr/private-box](https://github.com/auditdrivencrypto/private-box) |
| 6 … | + | |
| 7 … | +> When you want a message to be private, it is encrypted end-to-end with private-box | |
| 8 … | +So gossipers will still see the cyphertext of your message, but will not see the plaintext. best of all, the recipients (including the number of recipient!) is also encrypted, so a patchwork private message leakes much less metadata than GPG. (it's obviously a message for someone in the network, but there is no clues who*) | |
| 9 … | +> | |
| 10 … | +> * Excepting timing information. To obsecure timing information, you'd post messages randomly and relay encrypted sends. Doable, but quite a niche, will leave this for later, once more people are using the system. | |
| concepts/pub.md | ||
|---|---|---|
| @@ -1,3 +1,9 @@ | ||
| 1 | -# Pub | |
| 1 … | +# Public Peers, aka "Pubs" | |
| 2 | 2 … | |
| 3 | -To sync across the Internet, "Pub" nodes run at public IPs and follow users. They are essentially mail-bots which improve uptime and availability. Users generate invite-codes to command Pubs to follow their friends. The Scuttlebot community runs some Pubs, and anybody can create and introduce their own. | |
| 3 … | +To sync across the Internet, "Pub" nodes run at public IPs and follow users. They are essentially mail-bots which improve uptime and availability. | |
| 4 … | + | |
| 5 … | +The Scuttlebot community runs some Pubs, and anybody can create and introduce their own. | |
| 6 … | + | |
| 7 … | +## Invite tokens | |
| 8 … | + | |
| 9 … | +Tokens which may be used to command specific Pub servers to follow a user. These are used to join Pubs. | |
| concepts/capability.md | ||
|---|---|---|
| @@ -1,0 +1,6 @@ | ||
| 1 … | +# Capability | |
| 2 … | + | |
| 3 … | +> zooko recommended this paper paradigm-revised.pdf as a good introduction to capability systems that isn't 200 pages long ;) | |
| 4 … | +> (instead, only 22) | |
| 5 … | + | |
| 6 … | +- %Ff8Eu/CqkOsKzRrOKEIE2aqi3xYj0l9+wFvymAWBbe0=.sha256 | |
| concepts/stream.md | ||
|---|---|---|
| @@ -1,0 +1,5 @@ | ||
| 1 … | +# Stream | |
| 2 … | + | |
| 3 … | +> you can think of an array as a structure that you move past... like one of those fancy old libraries with the moving ladder. You move to the position the data is in, and the data stays put. A stream is more like a conveyer belt. You stay in one place, and the data comes to you. You just control fast it comes. It's a more restricted idea than the array, because with an array you can move backwards and forwards, but a stream can only pause or move forward (or abort) | |
| 4 … | + | |
| 5 … | +- %EkBhkSOAyuNpqLNGx1qW916/quYbZQ2yf5erHgxRMHc=.sha256 | |
| principles.md | ||
|---|---|---|
| @@ -1,0 +1,93 @@ | ||
| 1 … | +# Scuttlebutt Principles | |
| 2 … | + | |
| 3 … | +> secure-scuttlebutt is a venn diagram of the overlay between these two things: | |
| 4 … | +> | |
| 5 … | +> 1. avoid hard data replication problems (single author append only log, easy to express replication state & no conflicts) | |
| 6 … | +> 1. need to build engaging apps with viral growth (can apply web 2.0 playbook) | |
| 7 … | +> | |
| 8 … | +> It's a synergy between computer and human abilities. Computers move the data, but we levearge human filtering to solve the capital-H Hard Problem of decentralized systems: avoiding Sybil Attacks - humans are much better at detecting spam/etc than computers, and social apps have this "follow" or not decision naturally built into them. | |
| 9 … | +> | |
| 10 … | +> Not that I think social apps are the most worthy, but rather that its an easy design and can be applied to a wide variety of application needs, and then hopefully this will lead to another generation of protocol development. | |
| 11 … | + | |
| 12 … | +- %tN76rhfhajvOPB7qx0HZLIdjxzy3/5+h6eRv9aChGr8=.sha256 | |
| 13 … | + | |
| 14 … | +## Resilience | |
| 15 … | + | |
| 16 … | +> When it comes to emergency survival situations, it helps a lot if your survival equipment is also the equipment that you use every day. Then you know it works, is maintained, and you know how to use it! | |
| 17 … | + | |
| 18 … | +- %GAjTyOlMxMNGwKX+qeggyBzcWfJXLsBGkAIXuDibVPs=.sha256 | |
| 19 … | + | |
| 20 … | +## Governance | |
| 21 … | + | |
| 22 … | +> teaching a man to fish is the easy part, you must then teach his community how to [govern a commons](https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principles_for_Common_Pool_Resource_.28CPR.29_institutions) | |
| 23 … | + | |
| 24 … | +- %P3/ysGuvI9m4qCacXK+svHzoyMI4uJcymYOKAszJbiM=.sha256 | |
| 25 … | + | |
| 26 … | +> @yorkshire-moose we also use it to figure out what it means to have decentralized communication medium. | |
| 27 … | +> | |
| 28 … | +> Many of the concepts we have for thinking about this stuff are inadequate, | |
| 29 … | +> for example, you asked about your "account". On a normal website, your account is just a record in a database which says if you know a password, you can post as that account. Before computers, you might have joined a club and "signed up" in the club's membership registry (a book). Because computers where first sold to military, then large corporations. Of course computers are about accounting. | |
| 30 … | +> Keeping records about who owns what in books, or book-like systems. | |
| 31 … | +> | |
| 32 … | +> In a database system, all the power is in the database. It's often called a "single source of truth". Who can do what is ultimately controlled by whoever administers the database. | |
| 33 … | +> | |
| 34 … | +> Here, we have no central database to decide for us what a given action means, instead when you make a post or a 'dig' or change your picture, the other peers (or rather, the software they run) interprets that. A social consensus. Like how "blue" means what it does because we agree it does, and that agreement can also evolve. "blue" means, at least, a color, a sad feeling, and a certain type of film. | |
| 35 … | +> | |
| 36 … | +> But what are the implications of a system that doesn't behave like an accounts book? Where could that go? | |
| 37 … | +> | |
| 38 … | +> Just trying to understand what it means to be free. | |
| 39 … | + | |
| 40 … | +- %XMerwh7QoerzydCWsDlzgaLU/FD1vIjroHKYaf84B3c=.sha256 | |
| 41 … | + | |
| 42 … | +> It's true, developers do have a lot of power, and users have very little. "user" is another of these words which are problematic in this context. In terms of political empowerment, the implications of "user" is a lot like "pleb". Developers are like the landed gentry. | |
| 43 … | +> | |
| 44 … | +> But, there is a natural right that users always have: they can choose whether or not to run a given piece of software. Developers often act to hamper this right, for example, when you use a website your browser always "installs" the latest version. If you download a program and run it, you can at least, keep running the old version, if there isn't an automatic update mechanism (which empowers developers again). There used to be a lot of 3rd party twitter clients, but they stopped that when they introduced advertising, having a centralized system gave them the power to do this easily. The user still has the option to quit facebook, etc, but they must either take it or leave it. It's an ultimatum. | |
| 45 … | +> | |
| 46 … | +> But since secure scuttlebutt is a protocol, I can never stop someone from implementing, or choosing to use different software to interpret it. That is why I call it a "natural right" it's just there, basically a part of the universe, and you can act to hamper it, but you can never truly take it away | |
| 47 … | +> | |
| 48 … | +> But what happens if you instead act to enhance that natural right? | |
| 49 … | +If you make it easier for users to choose their interpretation of reality, and harder for developers to impose ultimatums? | |
| 50 … | +> | |
| 51 … | +> Developers get their power from users choosing their software, so if users have more freedom to choose, it will force developers to make better software. To create software that helps users live better lives, instead of herding them like cattle into advertising-milking sheds. | |
| 52 … | +> | |
| 53 … | +> But of course, to do that, we actually have to rethink a bunch of stuff. | |
| 54 … | +> | |
| 55 … | +> Ultimately, the question is, if we make a better system, will it win? | |
| 56 … | + | |
| 57 … | +- %hQMXHkZBPgO5x8HqiCeHxZKJWFferucYm00Hew9DHEU=.sha256 | |
| 58 … | + | |
| 59 … | +## Dogfood | |
| 60 … | + | |
| 61 … | +> always be rewriting everything | |
| 62 … | + | |
| 63 … | +- %hNetYXl04RcAu/+/uayn/Fh46+96DC7S+EV1Q8YPMf4=.sha256 | |
| 64 … | + | |
| 65 … | +> no, not sure. It's just a plan to get something working, so that we can build on that then explore further. | |
| 66 … | + | |
| 67 … | +- %jhevrzmT2QR4nCr2ZBpCe8JOgsV/J4NqSCg+0in7/rU=.sha256 | |
| 68 … | + | |
| 69 … | +## Modular | |
| 70 … | + | |
| 71 … | +> I think there is a sliding scale here. to build a p2p system currently you must understand crypto and distributed systems. That is much harder than plain web development. And then easier still is configuring drupal or wordpress. You can still make a hell of a lot with drupal, just by enabling/disabling/configuring modules. This is a pattern that has been demonstrated to be successful in practice. | |
| 72 … | + | |
| 73 … | +- %4etPxosu6kLyjZ2vqLxVFInbmQGXPVa2XcrTsKLICgc=.sha256 | |
| 74 … | + | |
| 75 … | + | |
| 76 … | +## [Uncapturable Distribution](https://github.com/mixmix/blogposts/blob/master/uncapturable_distribution.md) | |
| 77 … | + | |
| 78 … | +> Q: is the npm registry still open source? | |
| 79 … | +> A: no. npm, inc is now intergalactic feudal empire | |
| 80 … | +> | |
| 81 … | +> https://github.com/npm/registry/issues/41 | |
| 82 … | +> | |
| 83 … | +> _he who controls the spice controls the universe_ | |
| 84 … | + | |
| 85 … | +- %f6No+0gckncREe2dLT9fRw6MY99AH4SJC+2/bIUd9YI=.sha256 | |
| 86 … | + | |
| 87 … | +> @rabble just gave a very interesting talk at opensourceopensociety here in wellington. | |
| 88 … | +> | |
| 89 … | +> largely, it was about how twitter started out as an open platform, and then look a right turn and closed up - but what I didn't know, is that this was actually a reaction to an attempted hostile takeover. Basically, A there was a VC would tried to acquire all the independent twitter clients, and then have them also push to another service, shifting the data out of twitter.com's hand. | |
| 90 … | +> | |
| 91 … | +> This was the first I have heard about this, though, but it certainly gives us a more concrete threat model. Since we are basically trying to take the road that twitter didn't. | |
| 92 … | + | |
| 93 … | +- %QRBYdJkoOj1PlIpwhtEcXPBGIcXyugaVwiUhuTSr90g=.sha256 | |
Built with git-ssb-web