Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First Draft of Proposed NIP-76: Trace Resistant Private Posts #260

Closed
wants to merge 1 commit into from

Conversation

d-krause
Copy link

@d-krause d-krause commented Feb 15, 2023

Dear Reviewer,

I am not expecting this to get merged right away. I am only trying to establish the concept, get some feedback, etc.

I have a little more explaining to do with regard to this NIP, some of which could require 1 or 2 more NIPs. If needed, I was hoping I could group all of them together sequentially (ie 76,77,78), whatever the numbers may be.

The other two NIPS would focus on expanding NIP-06, to make it more secure and support multiple users (think like other facets of a user, not actual multiple users) from one wallet, and another to describe private profile metadata that can be used to control access to the user posts at the relay level.

I have been working on https://animiq.com/ since 2019, and as soon as I discovered NOSTR, I was like, WOW!!! It is exactly the protocol I have been waiting for to scale the animiq code up. All my source is on Keybase right now, I will be bringing it out in the open to github soon. Then I will work on a NOSTR client port and relay support.

Let me know any thoughts or concerns you have.

Thanks,
Dave
animiq@idk.email

@mikedilger
Copy link
Contributor

I presume the next nips (77 and 78) will detail at least how to exchange these new keys?

@d-krause
Copy link
Author

d-krause commented Feb 16, 2023

I presume the next nips (77 and 78) will detail at least how to exchange these new keys?

Yes indeed. And a few other details and clean up work. Just need time to focus on it.

@jeffthibault
Copy link
Contributor

jeffthibault commented Feb 17, 2023

If "Pay-to-Relay" (whitelistling pubkeys that have paid) becomes the preeminent way that relays handle spam, then it will become costly for the sender seeking privacy to use this as they will have to pay the relay cost every time they post.

@d-krause
Copy link
Author

d-krause commented Feb 17, 2023

If "Pay-to-Relay" (whitelistling pubkeys that have paid) becomes the preeminent way that relays handle spam, then it will become costly for the sender seeking privacy to use this as they will have to pay the relay cost every time they post.

I agree. But also perhaps freedom isn't free? Then again, I have not looked at the "Pay-To-Relay", is there a NIP for it, or a pull request to a NIP? (I did look before asking).

If I could see the spec on that it would help. One could for example pay to whitelist hundreds of pubkeys, a bulk rate perhaps? Again, though I need to see the spec before I could analyze the problem.

Worst case scenario, I was ultimately thinking of this as a pay to post protocol, not a chat storm of random jibber jabber, so this limitation might not be a bad thing. It all boils down to price.

@jeffthibault
Copy link
Contributor

There is not a NIP. I was just mentioning this as a possible concern.

@d-krause
Copy link
Author

d-krause commented Apr 7, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants