thoughts on having some event where a NIP-26 delegatee pubkey can be revoked?

* Delegator grants a delegation token to delegatee pubkey.

* Delegatee misbehaves (within the confines of the delegation token)

* Delegator publishes a “revocation” event, preventing delegatee pubkey from using the delegation token.

thoughts?

cc #[0]

I agree that a bundled experience has a better UX, let's ask to all the WhatsApp users that try to move between Android and IOS. But a relay is probably excessive as basic backup solution, a client can simply export a JSON blob with all the events or offer to encrypt and upload it somewhere. Of course the "where" can be offered by the client too, with a full integrated procedure.

#[12] the NIPs are the right place to define a standard backup format?

#[5] #[6] micro business idea ^

In more-speech I can now specify that certain relays only subscribe to my web-of-trust. These are my trusted contacts and all of _their_ trusted contacts. I'm using this on relays that are spammy.

Running Monstr.

#[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 ?)

3/ Next steps

Logical problems in my outline: please shout

I can do PM and QA => need motivated Dev

Need choose which client to build upon as a microapp

Cheers, pv

Zap Collections

A gamified content monetization concept.

TL;DR

You "collect" notes by being the highest zapper. A beautiful view of your shiny zap collection is on display at your profile. Author's can attach special privileges to their notes for zap collectors to enjoy. Collected notes are transferable.

Bidding Process

Every new note becomes available for collection. Users zap a note to try to collect it. After some time limit has ended, the user that zapped the most sats collects the note, and a shiny collectible version shows up in their profile.

Clicking on a note shows:

- the amount time remaining for bidding

- total sats zapped

- leaderboard of top 3 zappers

Bidding Time

A 24 hour countdown bidding timer begins once the first zap is made on a note. The timer resets every time the leaderboard of the top 3 zappers changes. After 24 hours of the leaderboard not changing, the bidding ends. Zaps can continue after the bidding time has ended, but those zaps don’t count towards collecting the note. That note is already collected, and so must be purchased from the current collector.

Programmability

Content creators can grant special VIP access, discounts, or privileges to the collectors of their notes. For example, notes could grant the collector:

- backstage access at the musician’s concerts

- a free daily meal at the owner's restaurants

- the ability to schedule a 20 minute video call with the content creator

- a claim to the first prints of the author’s new books

Transferability

Collected notes and the special privileges associated with them can be transferred to a different collector. Content creators can specify a transfer limit for a specific note, as well as a transfer fee (i.e. 0% to 90%) that the author collects every time the note is transferred between collectors.

Clients

Zap Collections is a powerful monetization concept for clients. Not only could the client developers become desirable collectibles themselves, but users will flock to whatever clients curate the best content and user experience. Zaps are a powerful content filtering mechanism to leverage. I suspect client developers will produce desirable collectibles themselves not only because there is prestige for collectors to claim a bit of history that marks a particular bug fix, feature upgrade, or nation state censorship event, but developers could grant VIP privileges and premium features to their collectors.

Relays

Relay operator notes could become desirable collectibles by granting access and features to collectors.

Content Creators

Content creators are rewarded for creating content that is

- higher quality

- more evergreen

- loaded with cool VIP access privileges and features

Curators

Users are rewarded for being early to discover great content creators.

Hopefully this post helps get some creative juices flowing for how Nostr can do collectibles the right way.

cc

@#[0] @#[1] @#[2] @#[3] @#[4] @#[5] @#[6] @#[7]

Dangerous proposition. Or safety feature?

NIP-86

An Event Kind that when signed with the correct key, nukes the relay. Dropping data from the database and writing random data to the disk sectors multiple times.

One thing I never fully understood was how can immutable types in purely-functional languages be performant at all. They can't possibly rely on copying all the time to remain "immutable", right? So what is the trick?