| … | … | @@ -6,10 +6,21 @@ your machine. There is no server, no account, and nobody to ask. |
| 6 | 6 | This is the daemon. It keeps your data, talks to other peers, and answers questions over a unix |
| 7 | 7 | socket. You read it through `favela-surface` in a browser, or the `favela` CLI below. |
| 8 | 8 | |
| 9 | | ## Running |
| 9 | ## Install |
| 10 | |
| 11 | Deploy is publish then install — there is no hand build, and the release carries prebuilds for |
| 12 | every platform: |
| 10 | 13 | |
| 14 | ```sh |
| 15 | pgh publish . |
| 16 | pgh app install pgh://<registry-key>/favela-peer --name favela-peer |
| 11 | 17 | ``` |
| 12 | | bare index.js # or the pgh-installed launcher, favela-peer |
| 18 | |
| 19 | ## Running |
| 20 | |
| 21 | ```sh |
| 22 | favela-peer # the pgh-installed launcher |
| 23 | bare index.js # or straight from a checkout |
| 13 | 24 | ``` |
| 14 | 25 | |
| 15 | 26 | Storage is `~/.favela`, socket `~/.favela/favela.sock` — `FAVELA_STORAGE` and `FAVELA_SOCK` move |
| … | … | @@ -49,25 +60,25 @@ contributes nothing — which is correct, and is why `favela missing` exists. A |
| 49 | 60 | different thing from a gap that is silently empty. |
| 50 | 61 | |
| 51 | 62 | **A post is a markdown file** — JSON frontmatter, then a body. It is mutable and edited in place, |
| 52 | | so the content hash changes on every edit and **the name is the stable identity, never the hash**. |
| 63 | so the content hash changes on every edit and the name is the stable identity, never the hash. |
| 53 | 64 | The bytes live content-addressed in hyper-overlay; the log holds a pointer. See `favela-markdown`. |
| 54 | 65 | |
| 55 | 66 | ## The three primitives |
| 56 | 67 | |
| 57 | | **Feed** — one identity's log. Its writers are that identity's devices, and its roster is flat: |
| 68 | **Feed** — one identity's log. Its writers are that identity's devices, and its roster is flat — |
| 58 | 69 | the only question is whether a writer is on it. You have exactly one. |
| 59 | 70 | |
| 60 | | **Room** — many *members*, each with their own devices, and membership is the audience. Two levels |
| 71 | **Room** — many members, each with their own devices, and membership is the audience. Two levels |
| 61 | 72 | rather than one, which matters more than it sounds: a role belongs to a person, not to a laptop. |
| 62 | 73 | The vocabulary is keet's — admin, moderator, peer, read-only — because there was no reason to |
| 63 | 74 | invent another. A DM is a room with one other member in it. |
| 64 | 75 | |
| 65 | | The engine underneath is **autobee**, not autobase. Autobase needs `floor(N/2)+1` indexers, so at |
| 76 | The engine underneath is autobee, not autobase. Autobase needs `floor(N/2)+1` indexers, so at |
| 66 | 77 | N=2 one member going offline freezes the view while it keeps growing, and it cannot heal by |
| 67 | 78 | dropping to one. A person's two devices make N=2 the ordinary case, not an edge case. Weights |
| 68 | 79 | retire that whole class of problem. |
| 69 | 80 | |
| 70 | | **Namespace** — human names that resolve to feeds. It is a *subscription*, not an authority: two |
| 81 | **Namespace** — human names that resolve to feeds. It is a subscription, not an authority: two |
| 71 | 82 | people subscribed to different namespaces resolve the same string to different feeds, and that is |
| 72 | 83 | correct rather than a conflict. We give up global uniqueness and get, in exchange, a name that is |
| 73 | 84 | always qualified by a namespace you can point at. Resolution runs handle → self-label → key, and |
| … | … | @@ -93,3 +104,7 @@ browser sessions, files and avatars, the mirror, the follow graph, search, notif |
| 93 | 104 | replication. All passing. |
| 94 | 105 | |
| 95 | 106 | Build order and the two-peer acceptance tests are in `hyper-social` #61 §10 and §11.2. |
| 107 | |
| 108 | ## License |
| 109 | |
| 110 | Not yet declared — `package.json` carries no `license` field and there is no LICENSE file. |