@dan_hassan we had some awesome conversation about making an offline sharding tool. @Kieran has already prototyped something with electron.

I suggeested we use this rad tool Dominic made which takes JS and jams it into a single index.html file (it's called indexhtmlify). Then we can securely give humans a file which they can use to manage their shards easily.

re: multisig version of the opinionated setup doc - wait till I've done a revision based on the notes my run through with @katekb

Here's a git-ssb address for Horcrux, the electron/react app for sharding and fusing keys. Very simple at the moment but open ended too. Personally I feel like both the electron app or using indexhtmlify would be a cool way of replicating this for easy offline use. I'm currently enjoying learning electron so will carry on using that and can indexhtmlify it when its looking half decent!

Note I'm trying my best to be aware of my social conditioning, having been brought up in a capitalist and puritanical society, and having worked in many conventional oppressive 9-5 jobs, social and interpersonal disciplinary mechanisms are ingrained, especially when it comes to work/money. These social structures I intensely dislike and I want to avoid as much as possible. Always open to help from others to assist in noticing my own conditioning. So if there's assumptions I've made, please flag them.

Also apologies if this is a bit haphazard, things are popping up all over the shop. I've tried to give it some structure...

Reflecting on the points in the experiment, thoughts emerging for me around distribution mechanisms include:

(a) Draw a regular amount once a month

• Maintaining our individual agreements with @Dan Hassan
• We each have a set rate
• Implicit in this then is transparency, since when sharing this responsibility, how much each person is paid is in the open.
• Does the group agree on consistent rate across the group? Then this is dished out pro rata.
• How do we value contribution?
• How is labour distributed in the group?
• What are the accountability / transparency mechanisms?

(b) Draw based on need

• May leave a surplus which is helpful as a common pool resource for emergencies
• Case by case basis means each eventuality is addressed. Processes can be established and shared across the group which address how the group deals with different cases/scenarios
• Much of it varies on circumstance - how much people need / otherwise earn
• Implies frank conversations about what our expectation is from the pot

(c) Allocation of funds based on scope of workload and expenses

• Group members scope out what work they're going to undertake for the next period (month / quarter / year)
• Plan finances accordingly (with room for error / value fluctuation in crypto markets - leave some of a surplus in the wallet to account for excess)
• Funds are allocated at the start of the period and each person proceeds with their own financing appropriately
• More flexible, allows for 'seasonal' approach to work or scaling up and down workload based on personal circumstances

I think (b) is a reactive mechanism, and possibly precarious as a wage system. It lends itself to more of a savings-pool / loan scenario, for example (b) would suit the following story:

Heart Attack!

Kieran's cat has its second bout of heart failure, poor little Catness/Katniss (we've never decided which...). The vet's bills ramp up to £2000 and he has 5 days to pay back (you can't place a value on life, she's such a babe). Kieran hasn't drawn from the mmt-multisig wallet in a couple of months. He messages the group through Patchwork and everyone agrees to release some Bitcoin funds to Kieran so he can cover his vet bills. @peg and @Dan Hassan both agree to meet up on Mumble the next day and release the funds to Kieran.

That leaves (a) or (c). I think the different between them is minor but distinctive. (a) is more stable, but could also lead to instability in the group, it could lead to judgement based on performance. (a) feels like it could become disciplinarian. Being paid upfront means the scope of your workload comes after the fact. Therefore your achievements become reviewed through a 'performance' lens and entitlement to the next pot of funds could be contingent on that.

I feel (c) is a proactive more empathic approach and ties into our currently mechanism for organising. It gifts a huge amount of autonomy to the individual as a member of the collective, which I personally favour. It also feels like it fits in with CoBudget. I'm aware of the problems that may emerge here. For example, how does (c) account for illness? (c) places a lot of weight on the individual to scope out their own workload. There need to be mechanisms for dealing with that.

The different approaches to me tie into different mechanisms of collaborating, and also skirt around what @Alanna covered when talking about 'Convergent' and 'Emergent' decision making.

Its possible none of that made sense...

@bobhaugen this actually happened last last year it just so happened it was during the Bitcoin spike and I was able to draw on some crypto to pay for her bills. But it could happen again at any time. She's on 3 different medications for her heart every day.

In a recent meeting, @Alanna floated these concepts:

I’d like to float the concepts of convergent vs emergent collaborative financial decision making. I have found they have very different properties and implications, in terms of the financial decisions and group dynamics, power flows, etc.

Convergent is the case where you have a pot of money in the middle, and you’re making decisions together as a group (through consensus, representation, fpp voting, or whatever process). An example of this would be a group on Open Collective that decides about spending the money via Loomio decisions, or a charity who elects a board of trustees that has meetings and decides the budget by majority vote.

Emergent is where everyone is empowered to make their own individual choices, and through the combination of all of those the budget decisions are made. Examples would be Cobudget, where each user gets a portion of money to fund what they want, or value accounting systems (sensorica,colony, backfeed, etc) that automatically share out resources based on how much work individuals have decided to do.

In my understanding the seed is more sensitive than the master public key (though i might be wrong).

From what I understand the seed is the master key

seed -> hashing function = master key

More thinking on this point needed, for sure!

One more point, that i already put in the first draft of the guide, was that i noticed if you enter the same public key twice, electrum will let you know 'duplicate key' and prompt you for another one. That is, theres no need to stress about getting muddled up when copying and pasting keys, no harm can be done.

Neat!

@Alanna - that's great! Super exciting. We get to run the ceremony distributed and async now

We're in new territory here, so it's an opporunity to write up an opinionated document in how to do this. I'll add it to my todo list and post it up for review.

I think it's going to be as easy as everyone starting a new electrum wallet, deciding the quorum, sharing our seeds async (likely in a private group). We'd then need to send the funds from the old wallet to the new wallet. Finally, we should run a ceremonial destruction of the old wallet file so that we don't get them jumbled up (though maybe that's a bad idea).

Hey folks,

Have made the async electrum multisig guide here: %t1puzQW...