We haven’t started to use Bitcoin yet if all we’ve done is take it off from exchanges

?

#[0] #[1] #[2] #[3]

BUILDING PRIVATE GROUP CHATS on NOSTR — a MICROAPP proposal

1/ Why?

Because we don’t want to use other corporate junk + it needs to be permissionless + users need to control their data + open sources + no CEO … 5 things that you can't get elsewhere even from bahamas-located Tether-controlled Keet.

Because once we have this we have build freedom’s best friend (thus fiat government’s worst nightmare): permissionless ability for citizens to self organize in groups and in turn for groups to federate. It’s the path towards private islands and island nation states.

2/ Key ideas and considerations

a private group chat is a GROUP PRIVATEKEY and PUBKEY pair

if you belong to a private group then this is an extension of your identity, like another layer or branch. No reason it can’t be done with Nostr client-side, no need for relay specifics

today when you belong to a private group chat (e.g. whats’app) it is just a shared secret in the sense that you all can decypher the msgs. This is done with GROUP PRIVATEKEY. We can leave the admin thing on the side for now. What’app/Signal/Telegram: you can’t really prevent bad actors anyways from leaking stuff, so we are not going to try tackle that here, just focus on the building private groups

there is no reason it can’t be done with Nostr client-side, no need for relay specifics.

POSTING: today when you post to private group chat, it knows it came from you and displays accordingly. Achieving this with NOSTR: you encrypt your msg with your personal PRIVATKEY then embed it within a message to the group using GROUP PUBKEY. Basically it is a DM with a public post inside. That way only pple with knowledge of GROUP PRIVATEKEY can read and there is no ambiguity as to who is posting. just need to define the encapsulation specifics but there is no reason it can’t be done with Nostr client-side, no need for relay specifics. (Open Q: can you DM yourself with Nostr ? )

outside interference and inference: outsiders don’t see private DM. outsiders can spam the GROUP if they know the pubkey (which is possible since the GROUP should be able to broadcast to the outside world as a GROUP (a moral entity) ). But I guess there are ways to deal with that: on client side (block?) and on relay side (private relay ?)

GROUP LIFECYCLE: there are 2 ways to approach this:

the simplest way: there is no admin role, it is all organized (aka setup) out of band by individuals who DM each the GROUP key pair. Super simple and good enough for many use cases. Obvioulsy there is no GROUP level key pair rotation, so you can’t ban someone (once in) and once disbanded the group history is “as is” … stored on some relays (if backedup + keys not lost). Obviously there is no out of band “tracking” who is in the group: group members infered on the client side by reading msgs. There is no way to prevent a bad actor from leaking and no way to recover. A good culture/hygiene would be for groups to have a clear policy: such as finite lifetime (e.g. 1or 2 years, once expire up to the group to create new instance and possibly upload old messages), msg rentetion policy (e.g. expire after xx months)

the more complex way: there is a group ADMIN with a MASTER GROUP KEY PAIR seed and who derives then multiple CHILDREN GROUP KEY PAIR (for example meant to be used for a period of time) and does the group lifecycle management. we can imagine a variety of permissioned/permissionless method to distribute keys, and in return have key features such as: delete member, refresh group key pairs etc… open question: how does it look to outside world when group is posting and keys have changed (only post from MASTER PVTEKEY but then gated by admin ?)

Cheers, pv

#[0] #[1] #[2] #[3]

BUILDING PRIVATE GROUP CHATS on NOSTR — a MICROAPP proposal

1/ Why?

Because we don’t want to use other corporate junk + it needs to be permissionless + users need to control their data + open sources + no CEO … 5 things that you can't get elsewhere even from bahamas-located Tether-controlled Keet.

Because once we have this we have build freedom’s best friend (thus fiat government’s worst nightmare): permissionless ability for citizens to self organize in groups and in turn for groups to federate. It’s the path towards private islands and island nation states.

2/ Key ideas and considerations

a private group chat is a GROUP PRIVATEKEY and PUBKEY pair

if you belong to a private group then this is an extension of your identity, like another layer or branch. No reason it can’t be done with Nostr client-side, no need for relay specifics

today when you belong to a private group chat (e.g. whats’app) it is just a shared secret in the sense that you all can decypher the msgs. This is done with GROUP PRIVATEKEY. We can leave the admin thing on the side for now. What’app/Signal/Telegram: you can’t really prevent bad actors anyways from leaking stuff, so we are not going to try tackle that here, just focus on the building private groups

there is no reason it can’t be done with Nostr client-side, no need for relay specifics.

POSTING: today when you post to private group chat, it knows it came from you and displays accordingly. Achieving this with NOSTR: you encrypt your msg with your personal PRIVATKEY then embed it within a message to the group using GROUP PUBKEY. Basically it is a DM with a public post inside. That way only pple with knowledge of GROUP PRIVATEKEY can read and there is no ambiguity as to who is posting. just need to define the encapsulation specifics but there is no reason it can’t be done with Nostr client-side, no need for relay specifics. (Open Q: can you DM yourself with Nostr ? )

outside interference and inference: outsiders don’t see private DM. outsiders can spam the GROUP if they know the pubkey (which is possible since the GROUP should be able to broadcast to the outside world as a GROUP (a moral entity) ). But I guess there are ways to deal with that: on client side (block?) and on relay side (private relay ?)

GROUP LIFECYCLE: there are 2 ways to approach this:

the simplest way: there is no admin role, it is all organized (aka setup) out of band by individuals who DM each the GROUP key pair. Super simple and good enough for many use cases. Obvioulsy there is no GROUP level key pair rotation, so you can’t ban someone (once in) and once disbanded the group history is “as is” … stored on some relays (if backedup + keys not lost). Obviously there is no out of band “tracking” who is in the group: group members infered on the client side by reading msgs. There is no way to prevent a bad actor from leaking and no way to recover. A good culture/hygiene would be for groups to have a clear policy: such as finite lifetime (e.g. 1or 2 years, once expire up to the group to create new instance and possibly upload old messages), msg rentetion policy (e.g. expire after xx months)

the more complex way: there is a group ADMIN with a MASTER GROUP KEY PAIR seed and who derives then multiple CHILDREN GROUP KEY PAIR (for example meant to be used for a period of time) and does the group lifecycle management. we can imagine a variety of permissioned/permissionless method to distribute keys, and in return have key features such as: delete member, refresh group key pairs etc… open question: how does it look to outside world when group is posting and keys have changed (only post from MASTER PVTEKEY but then gated by admin ?)

Cheers, pv

Easy answer: Bitcoin can’t be bad because it’s only a protocol.

Now it’s only as good as the people using it. If in a distant future good times have created weak men then it might happen that they change consensus rules or emission schedule

Further more let’s consider what bitcoin doesn’t do and that we need really bad: -how to collectively build stuff like roads schools hospitals orphanage etc

- how to welcome newborns in this world (bag of coins?)

QR code in the book to a Nostr note with audio or YouTube link

1 bow tie = 1 bow tie

WEF is most likely as bad as what all the comments have highlighted.

There is also a small possibility that this is just a grift: they try to make money by organizing conferences etc trough inflating how important they are

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1hyqrsvl6hle8r5rc9cpshesm0mpcee75tgde4p5lhke5h83dyqqqdwk7cp

About #keyrotation issue, proposal:

Let's have 2 npubs per profile. The master Npub is generated (preferably on airgapped seedsigner) and is the only one that is allowed to modify the master npub associated with the profile. The child npub is the one used for everyday signing and so on

If/when the child npub is compromised simply publish a profile update with new master and child npub. optionnally stamp blockheight+UTC after which the user wants to signal compromission

ideally the Nostr note publishing the new profile update should be QR coded from airgapped device

I know it's not perfect but it makes it already that much harder to break

until we are dependent on DNS we're kinda stuck even with DIDs... also we always forget about things like the proper nonces being used for signing messages etc.... we have no control over the client's source code and whether they are doxing or not

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1hyqrsvl6hle8r5rc9cpshesm0mpcee75tgde4p5lhke5h83dyqqqdwk7cp

About #keyrotation issue, proposal:

Let's have 2 npubs per profile. The master Npub is generated (preferably on airgapped seedsigner) and is the only one that is allowed to modify the master npub associated with the profile. The child npub is the one used for everyday signing and so on

If/when the child npub is compromised simply publish a profile update with new master and child npub. optionnally stamp blockheight+UTC after which the user wants to signal compromission

ideally the Nostr note publishing the new profile update should be QR coded from airgapped device

I know it's not perfect but it makes it already that much harder to break

until we are dependent on DNS we're kinda stuck even with DIDs... also we always forget about things like the proper nonces being used for signing messages etc.... we have no control over the client's source code and whether they are doxing or not

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1hyqrsvl6hle8r5rc9cpshesm0mpcee75tgde4p5lhke5h83dyqqqdwk7cp

About #keyrotation issue, proposal:

Let's have 2 npubs per profile. The master Npub is generated (preferably on airgapped seedsigner) and is the only one that is allowed to modify the master npub associated with the profile. The child npub is the one used for everyday signing and so on

If/when the child npub is compromised simply publish a profile update with new master and child npub. optionnally stamp blockheight+UTC after which the user wants to signal compromission

ideally the Nostr note publishing the new profile update should be QR coded from airgapped device

I know it's not perfect but it makes it already that much harder to break

until we are dependent on DNS we're kinda stuck even with DIDs... also we always forget about things like the proper nonces being used for signing messages etc.... we have no control over the client's source code and whether they are doxing or not

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1hyqrsvl6hle8r5rc9cpshesm0mpcee75tgde4p5lhke5h83dyqqqdwk7cp

About #keyrotation issue, proposal:

Let's have 2 npubs per profile. The master Npub is generated (preferably on airgapped seedsigner) and is the only one that is allowed to modify the master npub associated with the profile. The child npub is the one used for everyday signing and so on

If/when the child npub is compromised simply publish a profile update with new master and child npub. optionnally stamp blockheight+UTC after which the user wants to signal compromission

ideally the Nostr note publishing the new profile update should be QR coded from airgapped device

I know it's not perfect but it makes it already that much harder to break

until we are dependent on DNS we're kinda stuck even with DIDs... also we always forget about things like the proper nonces being used for signing messages etc.... we have no control over the client's source code and whether they are doxing or not

Once content is out , it’s over. It can be copied

Unless you find an negative incentive to prevent copying , like revealing private key … though not sure how

As soon as someone gets into public office, especially those I do not dislike entirely => I become part of the « opposition ».

Because it’s about checks and balances

How many times have we been deceived ?

We want to believe we can delegate managing our lives to others. But we can’t.

Taking charge is hard. Bitcoin show the path

This is the way

Soil moves over time => it may not be where you put it initially

No such thing as private property exists in nature in my opinion. However Bitcoin gets you the closest to it but not exactly. As many chance to guess your seed as there are atoms in the universe.

Still not “yours”

2

Try carni:Keto and zero processed foods (no powder). Works miracle. Zero sugar zero startch. Grow your own greens: it s proof of work and gives a good workout

GM, nouvelle résolution: ouvrir Nostr avant Twitter

Outlook, sales force , oracle

Bittorrent