@Kieran and I have been having the same discussion.

We're proposing a fusion between btc and ssb. At a meta level this can be seen as a prototype for how global singleton p2p tech (blockchains) can fuse with agent-centric p2p tech (ssb).

That which needs to be global (blockchain) will need to be run on a server so that a client app can broadcast transactions to it. That which does not need to be global can be gossiped across the ssb protocol.

Discussing this is likely to bring us to 'who is this for?' and 'why are we doing this?' which we might never know the answers to...

IMO what we have the opportunity to do is to highlight what is possible with a fusion of these two p2p technologies. I find this super exciting.

@Alanna @peg

One of the innovations we have been designing has been interdependent backups of wallet details which would make it highly improbable that a participant in a multi-signature wallet be able to lose their Master Private Key, all from within the wallet software itself. This is capacity is afforded by the context of operating from within a ssb-like protocol - a fusion of identity within a social context, with a client-side private key...

@noffle: "Re cyptocurrency in SSB: Are there risks to bringing a money layer to SSB? I can't help but think about the hurt and emotional challenges that the SSB grants brought to the community, and wanted to pose the question. Money seems to have a way of bringing out certain value sets in people."

Agree with all of what you've said noffle. Should clarify that the ssb component is about interdependent social backups. In our case we are making use of this affordance and possibly planning to weave this into a social multi-sig.

The same protocol could be used for any sharded secret (such as .ssb/secret)

The wider discussions about Money are certainly worth having as well.

My inclination without having heard anyone elses views are to focus on

Build a next-gen multi-sig wallet, designed for collaboration

Which can then lead into interfacing with:

Bring crypto into Cobudget or OpenCollective

Much easier to join forces with other projects such as Open Collective and Cobudget

I'm holding a super strong questions about what interoperability looks like with other systems. I've had so many boring conversations with users who've accidentally set up accounts with different email address for Cobudget ... and that project was never able to integrate magically with Loomio ... because making mapping between user tables is not a thing ... and that doesn't even scratch the surface of mapping groups ... and those projects have basically the same structured codebase ... mmm. This is one of my rants so maybe I'll stop and people can ask if they want any more clarity.

small detail: if pubs ran a bitcoin or ethereum node (they could mention they expose a cryptocurrentcy api in their pub-annnouncement) then you don't need the chain explorer website, also it can broadcast transactions for you.

secondly, money: the interface between scarcity and abundance is chaos. That's not gonna not happen just because we turn inward - but doing so will limit the impact that ssb can have. Personally, I want ssb to have a big impact - and I am very happy to see people exploring ideas like MMT on ssb.

@peg

Yes, I am suggesting we use ssb for a sharding secrets schema. @Kieran is now extending/adding a module to the ssb protocol which helps with this.

An interesting property of doing this "in-band" is that it then makes auditing much easier. At the moment auditing process is manual (peg, have you backed up your secrets? have the people that you have given your secrets to back it up? do we have a way of contacting these people in the case of you becoming unavailable, etc).

The above auditability is a effort and coordinating saving feature internally for groups, but also affords some interesting properties for collaboration across organisations. Here's an example:

Lets say the #ssb-grants and the #mobile-ssb-quests were both managed by different organisations in a multisig wallet on the above ssb underwritten protocol. Lets say each of the organisations wanted to offer a fusion-grant where there is an amount from each wallet offered for a shared project (something which helps both mobile and ssb protocol). Each organisation would be able to offer the other organisation an auditing review (which respects privacy) of how interdepnedently secure/resillient the wallets in question are. This is a bit clumsy in my brain - maybe a bad example. Will come back.

By doing this on ssb, you also get identity and messaging for "free". As an example, look at ticktack which is a blogging platform, but with messaging baked in. Imagine now that ticktack is actually a electrum-like-bitcoin wallet. This would mean all interactions and comilations of partial transactions can be gossiped through ssb (as you have mentioned peg). When a transaction have reached quorum it can then be broadcast to a server which can then broadcast to the bitcoin network.

I have noticed that we all seem to be coming to similar conceptions of the possibility space.

@peg @Alanna I really feel like we're on the right track here.

I have reservations about building a money layer into ssb, primarily because financial transactions causes frayed nerves and heightened tensions. Having a time-lapse when sending or receiving the monies might cause a bunch of extra payments / bugs / dud txs and a bunch of anxiety to boot. This could possibly be alleviated by smart implementation.

I guess my own vision for #mmt merging with #ssb (one of which I have begun implementing) are twofold, and have already been spoken here, but I will re-iterate / echo in my own slangalang. Many convo's with @Dan Hassan over the past week have focused on the following ideas...

• Social Backups -- a protocol for socially sharing private keys. This could be your ssb identity or your crypto private keys, with both 'in-band' (using #ssb) and 'out-of-band' (conversations / chit-chat / non-cyber-integrations) components to the activity. Create lossless data via a network of trust and minimize / remove bottlenecks*, single points of failure, etc. The aim being, you never lose your wallet keys, cause your buddies and their buddies can help you recover. I'm messing around with flume views and building out the relevant data structures which are the beginning of this process. @Dominic would be cool to hit you up at some point for a chat, you may be able to help clarify a bunch of questions I have.

* Being a bottleneck carries emotional weight. It's a lot to ask someone to hold onto a shard of your bitcoin private key and doing so bubbles up our conditioning and relationships (affected by class) to money. Making it so even if one link fails, others can recover, means, in a sense, lossless data. This can reduce the emotional burden to a point where people who were previously averse might be more interested in participating.

• Build a next-gen multi-sig wallet, designed for collaboration -- Yes to this, use ssb to gossip transaction data, create accountability in the multisig, sync relevant info from a blockchain node when connected and sync with others sharing the wallet via ssb. There are no multisigs out there that fulfil this.

Blending these two into a client-side app could be done, and perhaps done well, to create a distinctly social crypto wallet. And in essence this is a blend of 'centralised' and 'decentralised', where a singleton (blockchain node - a point of centralisation) deals with financial transactions while ssb gossips tx accountability data. I would add that I don't feel 'decentralised' is inherently better than 'centralised', each have their own applications.

It would totally play into our own dogfooding process, and I can think of other groups who might be interested in trying this out as part of the dialectical research linking development and real-world application / usefulness.

I'd also be interested in an integration with OpenCollective / CoBudget, though I'm also aware I'm super excited (and admittedly slightly attached) by the above.

Brain dump for the evening. x

@peg : "you've lost me a bit on your example with ssb-grants and mobile-ssb quests. For sure having inter-dependent backups between the two groups would help them support each other in case of loosing a key. But how does this help them collaborate with funding for a project with shared goals? Isn't the key recovery process only for 'emergencies'? "

Ignore me for now. I'm talking about 10 steps ahead which isn't super useful right now, other than to say - coordination amongst more complex groups/orgs can be aided with privacy respecting auditing. This was one of the takeaways from the 3 year EU funded research project called DCENT. I will try to dig up some of the research which highlights complex cooperative trading networks and how flows of information about internals of an org can help with things like writing mutual-credit. I should emphasise this is not about trustlessness but rather it is about de-risking relationships so that there isn't undue pressure put ON trust relationships, which can strain the trust... rather trust can be put into trusted governance, reporting and auditing proceedures - which can free up the humans to foster , hold and nurture the human-communication-relationship stuff which can't be "systematised".

peg: "Are you imagining some sort of automated propagation of shards which become shards of shards? Or even shards of shard shards mixed with someone else's shardshard. So maybe youre carrying shardshardshardshards for people you dont even know?

That sounds amazing! But mind bending! I think its gonna take me several days to figure out what exactly the implications of that would be..."

Yes, we're talking degrees of automation but with OPT-IN moments during the flow. TBH I am not sure I have ever seen anything like this in computing systems before. It might be a new thing (just using old tools, it's just that our computing patterns now afford new utilisations e.g. agent-centric append only logs allow automated shard distribution).

A.K.A Decentralised Password (secret) Recovery

At least on paper it seems possible to design this into protocol in the way that it's almost impossible to lose your secrets.

peg "Im trying to understand what sharing shards over ssb could help do that wouldn't be possible by some other secure communication channel, (eg: encrypted email or some mobile app)."

This is an example of "OUT OF BAND". You use signal, or pgp email to share your shards. This means there needs to be somewhere where you create a map to where these secrets live so that if you disappear the parties who need the secret can discover the secrets. e.g. if you leave one with you partner, then we of mmt would need to discover how to contact your partner.

An "IN BAND" approach, which is what we are looking at with SSB means that it would be possible to contact people, under certain conditions (which we could design), to recover secrets. This reduces the work that needs to happen to recover secrets.

In past systems this type of thing has be SUPER DIFFICULT due to the question of IDENTITY. e.g. if you disappear and your partner is contacted by phone by me - how does she know I am who I say I am? This is just one example. SSB also goes some way to solving the identity question and edge cases as IDENTITY is contextual within the community of people within SSB. Like Keybase, your partner could see the private message I am requesting a secret from is the account which your account has friended and has had many conversations with, etc etc etc

Run out of steam - keep asking the clarifying questions peg!

Suggest #lightning-network specific notes go in this thread?

%VCrfWd4...

@peg have seen this and like the thinking.

I have been thinking of setting up a https://github.com/btcpayserver/btcpayserver

Have also been thinking of setting up an electrum server just for learning