e1419d1787
%contact-store is responsible for sending updates about contacts, eg profile color. When it hears an update, it fans that out to its subsribers, unless that update is stale. If you reguarly fan out stale updates, then they reverberate across the network indefinitely -- we call this "echoing". To cut off this echoing, all edits have a timestamp, and we consider any updates from before this timestamp to be stale. Additions are separate from edits, and for them we instead do a value comparison on the contact -- if it didn't change, we consider the update stale. The problem with this scheme is that if an addition and edit happen one after the other in quick succession, you might have the following sequence: - add comes in with timestamp T1 - edit comes in with timestamp T2 after T1 - we hear an echo of the add, and that errantly applies because it passes our "did the contact actually change" check - we hear an echo of the edit, which applies because T2 is after T1 - GOTO 3 Each time we apply the stale update, we fan that out to our subscribers, and if any two hosts subscribe to each other, this will loop. This may even loop unconditionally because the ship that made the profile changes seems like it might not recognize that those changes didn't come from itself, so it sends them to all the groups it's in. If so, that's an important issue to fix. Fixes tloncorp/landscape-issues#1442 |
||
|---|---|---|
| .github | ||
| .husky | ||
| bin | ||
| doc/spec | ||
| extras | ||
| nix | ||
| pkg | ||
| sh | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .ignore | ||
| .mailmap | ||
| .nvmrc | ||
| .stylish-haskell.yaml | ||
| .vercelignore | ||
| CONTRIBUTING.md | ||
| default.nix | ||
| lerna.json | ||
| LICENSE.txt | ||
| MAINTAINERS.md | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| shell.nix | ||
Urbit
Urbit is a personal server stack built from scratch. It has an identity layer (Azimuth), virtual machine (Vere), and operating system (Arvo).
A running Urbit "ship" is designed to operate with other ships peer-to-peer. Urbit is a general-purpose, peer-to-peer computer and network.
This repository contains:
- The Arvo OS
- herb, a tool for Unix control of an Urbit ship
- Source code for Landscape's web interface
- Source code for the vere virtual machine.
For more on the identity layer, see Azimuth. To manage your Urbit identity, use Bridge.
Install
To install and run Urbit, please follow the instructions at urbit.org/install. You'll be on the live network in a few minutes.
If you're interested in Urbit development, keep reading.
Development
Urbit uses Nix to manage builds. On Linux and macOS you can install Nix via:
curl -L https://nixos.org/nix/install | sh
You can optionally setup Nix to pull build artefacts from the binary cache that continuous integration uses. This will improve build times and avoid unnecessary recompilations of common dependencies. Once Nix has been installed you can setup Cachix via:
nix-env -iA cachix -f https://cachix.org/api/v1/install
cachix use ares
The Makefile in the project's root directory contains useful phony targets for building, installing, testing, and so on. You can use it to avoid dealing with Nix explicitly.
To build the Urbit virtual machine binary, for example, use:
make build
The test suite can similarly be run via a simple:
make test
Note that some of the Makefile targets need access to pills tracked via git LFS, so you'll also need to have those available locally:
git lfs install
git lfs pull
Contributing
Contributions of any form are more than welcome! Please take a look at our contributing guidelines for details on our git practices, coding styles, how we manage issues, and so on.
For instructions on contributing to Landscape, see its guidelines.
You might also be interested in joining the urbit-dev mailing list.