Bivouac Wiki is web-of-trust decision software. The name comes from mobile ant nests composed of living members.

Ornithopter is a small business that provides managed hosting for it, however it's open source and you can run it yourself.

There are lots of goals for this software - but for now we're going to build out single-site polling, and slowly expand into the rest of the features.

What do you do with it?

weird, distributed playbooks and wikis with voting. Like if HomeAssistant.io automation playbooks were distributed and had voting. Or like Loomio, but federated.

Bivouac is a petname (& fediverse) based software & grammar for managing decisions across computers (hopefully in a healthy way).

For example, say you're a worker-run cooperative, a union, a volunteer project, or another form of collective or confederacy.

Maybe you have some decisions that you'd like to make as groups or as smaller teams? - This software allows those kinds of building blocks to happen, it's a governance sandbox.

We include an example for configuring meta-moderation via bivouac decisions. You could build your own complex governance playbooks.

Quick Overview

This is 8 things in a trench coat.

It allows you to define a group of users (called Crews); create roles within that group, assign permissions (called Mores), and define Choices which are governance templates for deciding actions. Those actions could be in the group software itself, pointed at other software, or manual actions.

Bivouac documents (called Bloat) are created on an editor (that you can run on your laptop or in the cloud). The documents are then published on a static hosting provider, where other bivouac editors can download and review them.

Users and groups adopt handles (username strings): users with one @, groups with two @@. These handles only have meaning when speaking about a particular network graph of friends; they aren't globally reserved and multiple people could have the same handle. Bivouac understands both Fediverse handles (@username@some-domain.com) and its own petname handles, called Phish.

Documents can be tagged by users to collections managed by curator roles, and the curator and author can separately choose to display the tag relationship (called Decals). This form of group-curated tagging is similar to Danbooru, an image tagging software. Unlike hashtags, which are globally namespaced, the curators of a tag can describe a tag with a short sentence, and it links to a longer article about the tag.

Users can configure how their feed is displayed, when they're notified, and even delegate their voting power temporarily (a concept called Liquid Democracy). Groups can specify in decisions how this kind of delegation power is regulated in a decision (for example some vote might disallow delegation, or require you volunteer). These choices are configured in Syzygy documents.

Some things this is not...

there's a particular "type" from Web3 and it's not welcome.

Bivouac has some rather odd design decisions giving it a unique flavor. It's meant to be more hospitable to community and less hospitable to bad actors. Rather than unanimous bandwagons, it's meant for allowing dissent and deviance to be expressed in a healthy way. As with any well-run software project, it does not give space for bigotry. Fascists, racists, transphobes, etc are not welcome voices on decisions.

With the web chock full of bitcoin and blockchain pump and dump schemes, it seemed like a good idea to build a reminder of what being outside the box should be like. f--- bitcoin/blockchains. This is just one silly project. It's more like torrents or indieweb, and we plan on making it compatible with ActivityPub (more on that later!). It's sharable, forkable, mirrorable, but it also embraces components of the old web, like running your own blog or talking to someone on an open protocol (AP would be preferred).

In contrast to DAOs, we make no grand assertion that humans can be entirely removed from the mix (your organization should still have a physical existence and/or a system administrator).

This software might occasionally get stuck and need someone in your group to manually fix it. That's fine; the decision and counting systems and state should all be pretty readable (flat XML files).

As with many problems, they can't all be fixed by software, it takes good volunteers, good moderators, with tools built by developers who listen to them. Sometimes it's better to focus on building good moderation tools.

Re: Premature Optimization

Forward to the nerds <3

Bivouac is not production grade, it's not a PhD thesis in anonymous voting or ring cryptography (this is plaintext voting, NOT a secret ballot). It probably doesn't stand the test as far as distributed systems serializability, it's not a MVCC or CRDT. It wouldn't stand up next to TUF, Sigstore, or Signal. It isn't the coolest petname system.

So, with that apology in advance to people who actually know stuff; if you are really good at distributed systems or cryptography, my condolences to your sanity. This best effort plaintext state engine is gonna be painful.

Still, it could be interesting to see how many bugs this has.

It's our hope that this can illustrate some forms of governance and collaboration that become possible in the digital world at different sizes of groups.

Re: ActivityPub

Doing AP correctly is hard.

Bivouac's whimsical focus initially started as a static site generator ("serverless" in the way that Sqlite is serverless, not the AWS kind). You could even theoretically toss around USBs among friends of Bloat documents.

As bivouac gets more defined, the particular ActivityPub grammar extensions needed to "bridge" the two can be proposed. Some items are relatively straightforward like nodeinfo or webfinger.

ActivityPub is much more complicated than "just RSS with push notifications". However, it's the one protocol that would be nice to bridge to (not bridging with ATProto, Veilid, Holo, Zeronet, etc).

Other parts of AP posts don't entirely allow for the same logical evaluations, but that's not a bad thing. Bivouac could run some groups or decisions in a reduced functionality mode meant for fediverse bridging. For example: Fediverse clients don't have encrypted messages so the decisions would be plaintext ActivityPub JSON.

AP has the most promise to fully encode decision and group logic entirely within itself - for example FEP-2100 details groups that are unbounded by servers. There are some components that could also be superficially connected, like MetaGov's governance gateway to OpenCollective. Logging in via AP is another FEP-d8c2/FEP-61cf. Other open protocols like supporting CalDAV for your native calendar application would be nice, or native RSS for rendered HTML sites.

Bivouac could run in local-only mode, fedi-only mode, bloat-only mode, or bridged. This also might be configurable per group.

With that out of the way, check out the other sections!

Initial Feedback

• no consistency model
  • will work on this later, want to get initial buttons/forms/algorithms in play and revisit MVCC or CRDTs or git-style merging
• vaporware
  • this is my worry (not finishing the demo app)
• maybe a demo would help explain it?
  • you got it!
• have you seen Nostr/Holo/Tahoe-LAFS/etc?
  • yeah, but I wanted this to be more indie-web-ish and activitypub-ish.