Dual ID and Petnames

Bivouac supports two styles of identity: fediverse, and petnames. A petname is a solution to Zooko's triangle, the trilemma that it's hard to have something be simultaneously human-meaningful, secure, and decentralized.

Bivouac petnames have meaning based on what a peer gives a name, they're a bidirectional relationship between keys and names. Spritely's take on this is pretty nice.

Phish names are non-global and thus not prone to cybersquatting. Value in a name should come from the friends, not from some Namecoin or cryptographic mining or DNS registry (which cost money or are complicated for end users). They only need to be unique to the friend or group.

They're potentially private (it's a preference you can set in syzygy), but sharing them with others allows you to build a graph of names, and build trust. It also allows you to find your friends again if you're lost.

You can simultaneously have a Fediverse handle and a Phish petname, they could match or could be different.

Character Restrictions

Markdown in bivouac looks up bivouac and fediverse handles based on a defined syntax. Fediverse handles take the form @user@domain.com, where Phish identities use @someone.else.phish. The pseudo-TLD .petname was also considered but would be long.

Handles are composed of the characters [a-zA-Z0-9_-]. They may not use the characters :, #, ., or @.

Web of Trust

Say you don't directly have a petname for a user, but a friend-of-a-friend does. In bivouac, so long as a user has a path to us, we can render an approximate name.

To do this, we order the friends along that path:

@"kevin".phil.dave.peter.alice.phish

Canonization

When an identity has not been confirmed by you as a user, we call that an "un-canonized" name (aliases you have not accepted are kept in quotes). Identities in bivouac are hyperlinked to a page where you can interact with them, for example to follow them. You can also canonize their alias, either freezing the long handle or creating a direct handle (@kevin.phish). Canonized names must be unique to the person who decides to canonize them (this will be more clear in the section on Cicada).

Where a user has both a fediverse and a petname, they are rendered together (in whatever order you like), for example @alice@cool.computer|@hacker_alice.phish.

Verification

Identity is mostly trust on first use, however there are a few niceties thrown in.

Bivouac can understand references to Fediverse identities. For example, on mastodon you can set a link in your profile to your blog, and as long as your blog includes a html link tag rel=me href="your-mastodon-account" , you get a "verified" checkmark on many clients. Similarly, Bivouac understands if you have linked a blog to both your mastodon and your bivouac usernames. A HTTP URL referenced in your phish doc that's on your blog, that contains your phish doc suffices. It also should eventually support ariadne.id and keyoxide.

You also have the graph of what your friends' friends call someone, and what aliases they have selected as a preference for their handle.

A user's page might express their health in terms of:

  1. whether you were able to reach their carrier sites recently
  2. whether they have good Karma
  3. whether their NS peers were reachable
  4. whether you cannonized their name
  5. whether their group agreed on the cannonization
  6. whether they're in a ban list
  7. recent posts and activity
  8. their fediverse handle
  9. their keyoxide ID and any verifications

Changing Key Records

the part that Soatok might think is just awful

Bivouac keys include one mechanism for changing them, that of "nameserver" records. For people unfamiliar with DNS, a nameserver is the place one asks for where a domain can be found (it's the root of their identity).

In Bivouac you can define a list of either:

  • a DNS TXT record (containing your phish record)
  • a HTTP URI (containing that file)
  • or another Phish friend you trust,

as the "nameservers" of your keys. This list of people each can be assigned a weight, and the name itself assigned a threshold, where reaching it means other clients will accept the key change. It might be possible to even define a Choice playbook for whether friends should trust the old or new name yet.

The HTTP URI or TXT records might be things you control, or might be set somewhere else.

For example:

  • alice
    • my blog: http://something.onion/abcd/
    • my Age key: abcdef...
    • my Minisign key: abcdef...
    • my NS record threshold: 8
    • my NS records:
      • 1: DNS: foobar.alice.com, weight 10
      • 2: DNS: coolstuff.blog, weight 3
      • 3: Phish: @phil.phish, weight 5
      • 4: HTTP: https://mastodon.com/@some_user/post132, weight 5

In this example, either Alice changes their DNS record, or both Phil and @some_user change their data.

Note that the old records might lag during a pending change (e.g. they might have 10 votes in the wrong direction) - Phish NS changes are important for your NS friends to update very quickly. This allows documents to continue to be addressed to you, and allows your Crew memberships to be updated quickly, etc.

Phish identities also define a TTL for refreshing, and a TTL for contacts to re-verify using a human action.

When the threshold to change a key is reached mid sync-cycle, the newer key AND the older key are referenced by default (encrypting to both, or allowing signatures from both), while human intervention is pending. This allows for documents in other folders mid-change to still be valid or seen by you if you're mid-keys (however only one key is valid for a vote or edit at a time, it just might be different on different hosts). Some of this is explained more in Cicada, and some in Bivouac's state machine. How you update identities or the steps your friends update identities with (for example using Syzygy) should be visible to both of you as parties.

Out-of-band verification

Phish isn't as cool as real systems for federated public key management. It still expects that you can actually reach the people you've given petnames to in person or via another means outside of bivouac.

That human action should be defined between you both in a friend/note memo on the profile (for example: on key/address change, verify out-of-band with me in person).

This human verification should DEFINITELY be done by those who are named as nameserver peers, and should Probably be done by those who aren't.

New Names

Phish aliases can be changed, this notification goes to your friends who can then update their petname tables and accept the new nickname. Note that since it has to be unique on anyone's list, Bivouac can quickly check your friends to see if they already canonized someone with that handle.

Keeping in touch

Finger tables, neighborhood maps

Rendering editors keep tabs on changes to identity records and will helpfully try to keep you from losing touch with friends, even if you haven't read your mail in a while and approved the new identity or address yet.

It keeps around a loosely up-to-date document similar to a "finger table" - except it's purposed for web-of-trust lookups. This isn't exactly like Kademlia or Chord DHT's finger tables (which are actually random and uniform) - and is instead based on how many hops away someone is. We call this the "neighbor map", and users can choose to opt-out of it.

Bivouac keeps tabs on:

    1. your nameserver Phish friends (always)
    1. any first-party article authors you've saved or canonized (anytime you're working on stuff)
    1. their second-party-connections (retrieved from 1sts)
    1. the 4th connections (retrieved from their 1st's next list)
    1. the 8th connections (retrieved from their 4th's list)

I might be slightly off by one but you get the picture. On visiting any of those indexes one could then jump peer by peer to reconstruct a valid list and hopefully get in touch with someone who knows where your friend went.

Network Repair Mode

Typically Bivouac will do this through osmosis by reading the first party article author's files. When a degraded social graph is detected, it might reach out one by one (to 1,2,3,4,5,6,7,8 steps away). It may keep as many connections in the neighborhood map as you're comfortable with storing.

If a new document is found that references an identity your editor didn't know, a finder subroutine can be started. Typically enough starter information should be in the document itself (depending on how old the document is, for example if they changed HTTP servers). Bivouac can also go actively hunting for that author, or just passively wait to fill in the details later. If an ID isn't known at all, it's rendered as quotes even up to the .phish part, for example if I haven't checked that alice's NS peers are actually online, or that dave is even a live ID, @"dave.alice".phish would be how it'd render.

Pinning and Following

what bivouac keeps around

In bivouac, your editor caches the things you mention you want to stay up to date on. Then, when edits come in (like a friend changing servers), it will helpfully keep them fresh and up to date locally.

Bivouac will download the new version and wait for you to approve replacing it in the cache (next section). As discussed in cicada, it does not have to immediately mirror the new version unless configured to.

Bivouac doesn't /have/ to go see the source document on a source server, and could pick from any random mirror. It first checks the indexes for any updates (cicada explains this).

Next-of-kin

Groups define a "succession" process, but phish identities define a similar thing, a "next of kin" process, to either recycle, memorialize, or takeover a petname. You might also decide that nobody is allowed to apply for certain names.

ActivityPub has a similar thing for either transferring a handle between servers or otherwise deleting a username.