micropagaments in nostr to avoid spam?

[ghost]

Hi.

I would like to contribute to this protocol. I believe this protocol is quite interesting and innovative. About the idea of contributing, I initially thought whether the nostr protocol would allow micropagaments, as proposed by W3C.

A relay can charge a fee (the negotiation of that fee is outside of the protocol for now) from users to publish there, which ensures censorship-resistance (there will always be some Russian server willing to take your money in exchange for serving your posts).
If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays.

There is a site called fosstorrent, it's like a "relay" where you have access to Linux distributions, open software. The fosstorrent site, from what I understand initially indexes torrent file addresses, which does not contain the file in it, but the address where the file is. So,

I was reading the draft nostr protocol and noticed that there was no recommendation on the idea of requiring payment for publication or retransmission. As I said initially, there is a W3C proposal on micropayments, I just don't know if it would make sense for the nostr protocol. Therefore, I open this issue so that someone can better evaluate my question and whether or not it makes sense with the protocol proposal, so that someone can add the W3C proposal to the micropayments in the nostr.

Initially, I think if every relay has some privacy, security and control policy this is good. When I say about privacy, security and control policy, I refer to the idea of having some form of authenticity, integrity, confidentiality and availability. Sites like fosstorrent are interesting as their content is transparent and public. But the general problem with this type of approach is that there are cases of use where this may not work.

In cases of spam, for example, although some relay do not want spam. This does not prevent others from using spam. This could only work if all relayers cooperated to avoid spam, which is a problem cited in the ActivityPub protocol in comparison to the nostr protocol. For example, they (users of ActivityPub protocol) could consider a certain content like spam and the content is not spam. Simply, they (users of ActivityPub protocol) could consider what is not spam as spam because of the fighting fight against the established, for example: you like basketball and someone likes books there may be certain conflicts of ideas, relationship or interest.

I think the general problem always of any other technology has always been or is the idea or problem of: freedom, organization, equality and communication. Much of some technology tries to innovate in this regard or some technology tries to solve this problem somehow. Adopting the idea of micropagaments is not a general idea to solve the problem of spam, communication, privacy or even the general security of the nostr protocol, but it makes room for the dialogue of interesting alternatives to this general problem.

A conceptual view of this described idea would be:

alternatives
Although initially the idea of micropayments to avoid spam is favorable, I still think of other alternatives to prevent spam, complementary or not to the idea of micropayments. I would like to contribute to nostr, I recently thought of a collection of ways or alternatives or ideas to avoid spam, malware etc in nostr. This list involves the central questions:

• How can we prevent spam, malware in nostr?
• How to ensure greater security, privacy, control and, at the same time, auditability, authenticity, transparency, reparability in case any user action could compromise the network?

Part of these lists of general ideas, start from the idea of ​​the “account verification decision process” which is sometimes a decision between different replicators, people or even the system. About those general questions or idea: “account verification decision process”, here is a list of ideas or ways to deal with certain things:

• There are smart contracts that could be useful to validate certain content than others. Which may or may not be a complementary idea with the idea of micropayments. For example, in the same way people can be paid to store certain content that can add spam. The system itself, if it recognizes this flaw in certain content, could withdraw the content in question and reimburse another person who was the victim of this spam through the money that was sent for content recognized as spam, malicious, etc. But since I'm talking about micropayments, I'm going to leave one idea of ​​smart contracts aside. I would like a general opinion on the idea of ​​adding micropayments to prevent spam from some nostr server/client.
• an idea: we can have a multi-criteria process to address the issue of spam in nostr. For example, adopting open badges to accredit users when they conquer a certain space in the nostr. It could make things safer, more transparent.
• Another partial solution would be to use Filecoin proposal to allow certain things to be stored or retransmitted if they are of good quality, which can be paid for. It is a different idea, but at the same time complementary to smart contracts and micropayments.
• A form of security I thought would be adding routes or encapsulating routes like tor to prevent them from knowing the location or ip. I don't know if this was thought or will be thought, planned.
• Another way is for you to be recommended by the community itself and, accordingly, to have a verified account on nostr: Social networks like Clubhouse only allow you to have an account or join if you are exclusive or a guest. We can use this same approach, to enter nostr it would be necessary to enter some development community or some scientific, academic teaching or research institution.
• Another way to avoid spam is to adopt the idea of open badges, which is something that is can available: As you gain confidence, you earn open badges which are badges that demonstrate the level of confidence you've earned. Communities such as Discourse address this concept, but it is not just something unique, other criteria are adopted. So we may have this feature on nostr. There are things like ntfs that can be used or not in this sense
• Another mechanism is to adopt the idea of preventing or limiting a certain number of messages in any nostr. This limit can be monthly, yearly, weekly, daily: Things like email have a limit on the amount of messages like 500 messages a day etc. Why don't we have something similar on nostr?
• We can an account was verified under the verification criteria logic challenge: We can do account verification monthly, periodically, daily with some challenge. Thing like email has captcha process and other means of captcha, hcaptcha etc. Why isn't there an account verification process with some monthly logic challenge in nostr?
• We can check an account by statistical analysis, graphic: For example, some social networks can identify certain spam behaviors, for example the use of temporary emails or any similar ways.
• Another way is to add the user in a kind of slow response, where it takes a while for an nostr to be written or read: Things like email have the "greylisting" process, where the email message takes time to send. Which to some extent prevents some spam. Things like messages can have a response time to prevent spam within nostr. For example, it might be possible to schedule a fixed time where messages are received in nostr.
• Check account by number of followers: Things like YouTube allow you to have a custom address if you have x number of subscribers, for example maybe 100k followers or something. I think it would be interesting, in case the other spamming approaches don't make sense to adopt the idea of ​​x amount of followers to get the account verified.
• Check account by Webmention: There is an interesting protocol called Webmention. Webmention is a W3C Recommendation that describes a simple protocol for notifying any URL when a website links to it, and for web pages to request notifications when someone links to them. When we want to verify the impact of a scientific article, we base ourselves on the idea of peer review. This can be done by adopting the Webmention protocol to analyze the number of quotes or retweets a message has had and its reach.
• Limit on the amount of written text: Twitter itself has a limit on the amount of text written for example 255 characters. We can have a limit on the size of the message so as not to compromise sending the message to one or more replicators in the nostr.
• Security aspect for nostr: QUIC or "Quick UDP Internet Connection" is a new encrypted transport layer network protocol. QUIC was designed to make HTTP traffic more secure, efficient, and faster. Theoretically, QUIC has taken all the best qualities of TCP connections and TLS encryption and implemented it on UDP. can we use the QUIC protocol in nostr? Have you all thought about adding QUIC+nostr?
• Reporting channel limit: Things like Youtube has a "strike policy", each "strike" means the loss of reach of the channel or even the loss of sponsorship, reputation or visualization or the permanent exclusion of the channel. We can have in the nostr protocol a way in which the replicators by concession do not convey certain contents. This can be done by not complying with the security policy that the user signed or paid for in some smart contract.
• We can an account was verified under if has an active subscription to nostr: If I pay something on a monthly subscription, it would make sense to have a seal of authentication from my account. Things like Twitter Blue adopt this measure, although other social networks feel that this is more or less correct. If I pay for the monthly plan from any replay for nostr I could have an account already verified.
• Another way could be through a personalized email with a specific domain: For example nostr relays may require some authentication or custom email domain for that nostr works
• not allowed list: things like email contain a list of ips, addresses that are banned because they are spam or malware. nostr replicators may have a list of ips, addresses that cannot be replicated or will not be replicated due to violation of some smart contract or behavior. I wonder how I could add a list of keywords or certain messages or nostr replicators that can be allowed or not allowed
• Claims about certain misconduct may be made by official, unofficial or community broadcasters. Assuming there is a government relay, one or more people can denounce another user for bad practice, wrong for a government agency that has a private relay of messages received anonymously. Assuming another case, if the user sends a larger amount of message as spam, official, unofficial or community relays can block this amount of message automatically by some smart contract or even as a message filter
• content moderation:
  • perhaps there could be a reward among nostr users for moderating content that doesn't follow good guidelines, a rating level where society, regardless of people, says content can be valid or not. For example I am not very fond of things like spam and I can moderate content that I believe is spam, of course I may not be the only one as there is a peer review process going on by our nostr. There would then be, in that conceptual sense, certain relays that disseminate messages or users for the purpose of moderating the network. If this moderation is wrong, such users can be blocked on the network and the user's messages that were blocked can be recovered with granting
  • a voting system for certain content

why this alternatives?

• As you gain confidence in the network and through a meticulous process, detailed about your behavior in an automated way by an AI in the nostr, certain restrictions are left aside.
• This is a concise and logical list of good practices to avoid spam, these measures could be implemented automatically by some artificial intelligence algorithm or even could be done through smart contracts (which are based on general rules) that people sign
• Much of what is written here can be found in the protocol proposal itself
• We can provide a general nostr usage guide for people to use in the best way. It is a general rule in any programming or design language a set of rules, in this case here is a general set of practices or rules to avoid spam or limit the amount of spam in nostr
• All these lists of rules, conditions or good practice guides are made as self-censorship not of the nostr protocol itself, but of the limits of dialogue and people's tolerance. This is done because people have certain limits or conditions, as I said at the beginning, there is usually a spam behavior or pattern. In addition, there is general non-spam behavior. These rules, conditions or best practice guidelines are used by any software or protocol such as email and are personal and circumstantial observations
• Part of those ideas is to create a safe environment for content creators and the audience of content creators
• I think that each nostr message is a newsletter that the person can receive updates or not. like the newsletter, subscribers can choose to receive official messages from a channel that replicates or maintains the messages or not or with pay or not
• When I say "all these lists of rules, conditions or good practice guides are made as self-censorship not of the nostr protocol itself, but of the limits of dialogue and people's tolerance" I am referring to the idea of having an "intelligent" system enough or efficiently to moderate certain content. As an example, we have smart contracts and the way each person uses the nostr protocol is part of that, part of the assumption of a certain limit or purpose for which nostr can or is used
• databases have certain physical limits for storing, transferring and processing data, I wonder if there wouldn't be a limit or suggested limit in the nostr for this
• For a beginner or end user, the process of categorizing things is something to do. A general suggestion would be to adopt some categories that some nostr application is or can be used
• I think as possibility if nostr could replace email or add new feature to email
• there may be relays that tell where that message is conveyed
• part of what i'm writing here is part of the bitcoin proof of work process, but applicable to nostr.
• nostr is a protocol that looks like ted nelson's idea, in the sense of being closer to a decentralized hypertext
• this entire account and content verification process can be transparently informed to the user

[HonzaMikula]

I was thinking about something similar. How can we introduce subscription models like Substack that would work over Nostr? To achieve that I think we would need to use similar mechanism that you're describing.

[ghost]

Hi HonzaMikula.

I was thinking about something similar. How can we introduce subscription models like Substack that would work over Nostr? To achieve that I think we would need to use similar mechanism that you're describing.

I wonder if there could be some proof of work on content moderation and account verification between different people to nostr relays.

[ghost]

I would like to contribute to this protocol. I believe this protocol is quite interesting and innovative. About the idea of contributing, I initially thought whether the nostr protocol would allow micropagaments, as proposed by W3C.

Some ideas have already been integrated or are open. Please check it out here:

• NIP-43: Bitcoin-Funded Public Keys to Prevent Spam: "This NIP specifies that Nostr relays can implement a filter to check the balance of a bitcoin address derived from a Nostr public key. The filter will be triggered whenever an event is received from a client. If the current balance of the bitcoin address is less than the minimum configured by the relay, the message will be rejected."
• Polls RFC #69: "Poll notes are paid poll events on nostr used to conduct quantitative opinion polls that users can vote on with zaps"
• Proof of Work Service Provider for Nostr
• NIP-11 extension for Relay Limitations
• NIP 58: Badges: "Three special events are used to define, award and display badges in user profiles"
• Publish by peers
• Update NIP-10 to clarify usage of reposts and quote posts
• faq: Is there any proposal in nostr to schedule notes or events?
• smart contract in nostr?
• Reputation data-type
• Nostr apps bring data subscription fast to there monthly limit
• Newly proposed NIP - Matching demand with supply
• Suggestions about deletion
• NIP IDEA: New note Really Simple Syndication
• Relay-to-relay connectivity for user search
• Feature request : filter messages by language
• [NIP-01] Multiple values for filter conditions
• Is there any mechanism for followers to send feedback: like, dislike, comment, share?
• Enhanced proposal to NIP6: Multi-seed nostr key pairs

[ghost]

Hi HonzaMikula.

I was thinking about something similar. How can we introduce subscription models like Substack that would work over Nostr? To achieve that I think we would need to use similar mechanism that you're describing.

We can use the xanadu text transclusion model. Please, read this text:

"Xanadu seeks to do away with the limitations of the structures of literature as we know it today: movies, music, the web, books, magazines, radio, television. Xanadu has a radical system of copyright that permits and rewards everyone to quote anything in as full a context as needed. Content creators are financially rewarded when others include part or all of their works in another. This will happen instantly and automatically, making the services of lawyers unneeded."

With text transclusion, we can get the idea of micropayments. Recently, I see about transcluding nostr to make this model possible. The citation of the text can be found in https://hyperworlds.org/architecturemind.html and here: NIP IDEA: New note "transclusion"

Another partial solution would be to use Filecoin proposal to allow certain things to be stored or retransmitted if they are of good quality, which can be paid for. It is a different idea, but at the same time complementary to smart contracts and micropayments.

This is another good idea for micropayments

[HonzaMikula]

I love that idea!

[ghost]

Hi HonzaMikula.

I love that idea!

If this is something real, true and sincere. I would like to say that I appreciate your feedback.

• do you think this is a good idea seriously?
• could you help me create a NIP about this idea? (yes or no)?

note: I'm afraid of being sued these days. So a safer option is to use nostr or any decentralized messaging protocol. In that sense, if this idea of ​​adding micropayments is interesting. I would like to help the nostr community. I would be happy to help the nostr protocol or community nostr.

[HonzaMikula]

• do you think this is a good idea seriously?

Yes, I do. For many years (even before Nostr) I was working on this concept of subscription for newsletters (created by editor) that would be composed from articles, tweets, and other content from other authors. User by subscribing such newsletter would get access to all the content that is "embedded" to the newsletter. Authors that were included in the newsletter would in return get some share from the Editor's subscription.

So, pretty much similar idea what you're describing.

• could you help me create a NIP about this idea? (yes or no)?

My technical skills are limited (I'm Product Manager) but definitely would like to help you anyway I can.

[ghost]

Hi HonzaMikula.

Yes, I do. For many years (even before Nostr) I was working on this concept of subscription for newsletters (created by editor) that would be composed from articles, tweets, and other content from other authors. User by subscribing such newsletter would get access to all the content that is "embedded" to the newsletter. Authors that were included in the newsletter would in return get some share from the Editor's subscription.
So, pretty much similar idea what you're describing.

thanks for information here!

My technical skills are limited (I'm Product Manager) but definitely would like to help you anyway I can.

We would need someone's support to develop this NIP. My knowledge is in the technical documentation, frontend or design. I still didn't know much about project management or even product management.

Initially, I thought about personalized newsletter subscriptions. Instead of subscribing to a single journal, why not subscribe to a range of journals?

Please, see this: NIP IDEA: Categorization of relays: "This document aims to idenfify and categorize types of relays. The purpose for categorizing relays is to increase the confidence metric who uses the nostr network protocol. This is important to avoid unnecessary censorship or add only necessary censorship as the obvious becomes impossible."

use case NIP for categorization of relays:

• A secondary and important objective is to group different relays into general categories, to reach certain contents more easily.
• Users can post texts in relay groups or join relay groups.
• It is possible to block general groups of relays if the user wants to.
• User groups can check groups of relays.
• users subscribe to a set of relay groups.
• Another goal I forgot to mention is that the categorization of relays is done by metadata. In other words, it can be interesting information for most people, who want to customize the newsletter according to the subject of interest. Example,

twitter

NIP for categorization of relays:

{
  "pubkey": "ghost-dev-nostr",
  "kind": 30009,
  "categories": [
    "anime": ["relay.sample.io", "relay.sample1.io", "relay.sample3.io"],
    "fashion": ["relay.sample.io", "relay.sample1.io", "relay.sample3.io"],
    "nostr": ["relay.sample.io", "relay.sample1.io", "relay.sample3.io"],
    "bitcoin": ["relay.sample.io", "relay.sample1.io", "relay.sample3.io"]
  ],
  ...
}

NIP for categorization of relays and frontend

Do you think this idea makes sense?

[milahu]

please someone fix the title

-  micropagaments
+  micropayments