@ Basanta Goswami

Ratings

A NIP for ratings.

Existing PRs This one has a lot of feedback but the PR has not been updated with it: https://github.com/nostr-protocol/nips/pull/203/files

You can rate other users like: json { "kind": 310xx, "tags": [ ["p", "b1a649ebe8..."], ["d", "bitcoin-knowledge"], ["rating", "$n"] // 0 < n < 100 ], "content": "He doesn't know anything about bitcoin but likes to larp", ...other fields }

The d identifier is for the topic that you want to rate the pubkey about. Standard d tags can be: notes, articles, videos, shorts, livestreams, nests, marketplace. We can also have ["d", "trust"] for trustworthyness.

Instead of parameterized replaceable events, we can also have non parameterized ones, with a single p tag and multiple rating tags : json { "kind": 110xx, "tags": [ ["p", "b1a649ebe8..."], ["rating", "notes", "100", "God tier shitposter"], ["rating", "trust", "0", "Still hasn't paid back my dues"] ], ...other fields }

We can also have another event kind for recommending services on nostr, that extends this idea of ratings. For now we only have relays and NIP-96 file storage servers, but can have many more.

json { "kind": 330xx, "tags": [ ["d", "...."] ["type", "relay"] ["u", "wss://alicerelay.example.com"], ["rating", "90"] ], "content": "This relay is for bitcoiners only", ...other fields }

Self Notes

Encrypted notes for self reference.

json { "content": "I met this guy at nostr orgy", "tags": [ ["d", "..."] ["p", "b1a649ebe8..."], ], ...other fields } These events can have a single e, p or a tag. We can make use of concept of rumour and seals from NIP-59 (Gift Wrap) to encrypt the event its creator. Don't need the gift wrap part.

Use Cases

When you follow/mute someone or add them to a list, you can add a note about them for your own reference. You can secretely add a comment on a shitcoiner's post and timestamp it using OTS, and then reveal it when they get rekt. But I am not sure how you'd reveal the decrypted message without exposing your nsec.

Pokey Pokey

First idea is an event with kind:200 that contains a plaintext message in .content, with a single p tag. It is interpreted as a writing on the timeline of the user with tagged pubkey. Kinda like writing on the wall of someone on Facebook. It's for things like asking "Hey @someone, when is the price of your product dropping?" without the message reaching all your followers too.

The second one is a terrible idea. No one should implement it. But at the same time I want to do it so badly. Event with kind:300 (could be encrypted using NIP-44 and NIP-59) that tags a user and pokes them. Why? Just because. Now the poked one has to figure out why the other guy did that.

Internet Archive Explorer

Basically [this idea from Gigi][nostr:note1mqe0y0vfyzck2yqnfkmgnq8kzr8zvrmyzay4jq58s0muhlgldzsqq4el0k]

Here is what I think will be easy to build - Scheduled and live watch parties similar to live streams and nests - Chatrooms like the ones used there - Highlights from different shows/episodes - Option to self host some data in case Internet Archive goes woke one day and deletes something

POW Tokens

A POW token has the following format: <hash>:<nonce>:<target>:<URI>. The hash is the SHA256 of everything after it. The URI can be any URI that you want to add POW to. It can be "nostr:npub..." or "wss://relay.example.com" or anything else.

These tokens can be used in Authorization headers while making HTTP requests, or added to notes to kind:0 profile metadata events to mark yourself as non spammer, or used by other protocols that have nothing to do with nostr. If you mine any nostr event like the kind:0, then you loose the POW when you decide to update it. With the POW token, you can reuse them in the updated events as well. We can also have events with a new kind for gifting these mined POW tokens with the recipients "nostr:npub..." inside. It will make more sense when we come to index relays.

Index Relays

Index Relays are a relay client hybird that only tansmit kind:10002 (relay list metadata) events. I need to explore if reusing the BitTorrent DHT for this will make much sense. Otherwise we can build it purely on nostr as well:

• Store kind:10002 events of anyone as long as those events have sufficient POW in them (as a tag containing the POW token)
• Keep a track of n other of index relays
• New index relays mine their URL using the POW token concept and announce their presence to the network
• If the relay can't find an kind:10002 event for a given pubkey, they can
• act as a client and ask their known index relays for the event and return it to the users
• reply with their known index relays

The idea is that, given an npub, we can do our best at finding where they post to. It adds more complexity but I think it's worth having as a fallback for when clients just can't find any information about a user in their configure relays.

Index Relays Having POW tokens be the criteria for acceptance means users don't have to subscribe to a bunch of different services to prove they aren't spammers. Also these are probably going to run by people who want to support the nostr network.

We can do distribution of the data so that they are pretty evenly distributed among the index-relays. If we allow these index realys to have their own nostr keys, then we can make them store events only from their pubkey neightbours.

Zap to Reply

Before your client posts events to the read relay of another user (in case of replies, DMs etc), there can be standard way for the client to ask the relay if they are going to accept events from you. That way, it can display information to you like: "21 sats to reply". If relays allow you to write to it after the initial payment, then the comment box remains open, otherwise you pay everytime you reply to them. Relays may allow you to post their even when are not a subscriber, if you are in the social graph of the user.

We can even do zaps that are split between the user and the relay too.

Also it allows us to do the equivalant of blocking DMs, hiding/deleting replies to your post etc, by asking the relay. It might be prefereable to muting someone, when you don't want your followers to see their comments under your posts either.

Lists v2

Semisol mentioned in a Telegram group that huge lists are a problem. Once you add thousands of items to a list (like a music playlist) it becomes very difficult to work with.

I am thinking of two solutions to the problem: - Meta-lists that point to part n/m of other lists. These events will define a list event as page 1, then another as page 2 etc. - Add, sub events to a list. You create events defining the addition, and deletion of items from a list. I think Semi was thinking of this. This might become a implementation nightmare though.

Nostr Tabs

Inspired by Melvin Carvalho's idea. Users make a group, add others, and keep track of who owes whom how much. He also menioned OpenTabs, need to find what that was about. This idea can be further expanded to include services who offer credit to people based on their financial history etc. I can see how cashu mints fit into this as well. Will expand on this idea later.

Nostr Dictionary

The idea came [while browsing urban Dictionary][nostr:note1y60d2hc25h34emrlxnd5qpc4q80vnsytf4zncfjnm3elpwq92musyedhza]. Now that Pablo has created Wikifreedia, I can steal his ideas, build a client for dictionary entries. It needs a language tag (so do long form content and wiki entries).

Nostr Canvas

Drawings

Nostr canvas is defined as a virtual canvas where people can draw anything using nostr events.

json { "kind": 33000, "content": "#ff0000", // HTML color code "tags": [ ["d", "100:4224"], ], ...other fields }

In these events, the .content is a HTML color code: - keyword name (red) - hex (#ff0000) - RGB (255,0,0) - HSL (0, 100%, 50%)

The d tag is of the format of x axis value : y axis value in terms of pixels.

Graffiti

We define public canvas drawings as events with kind:33001. They are also supposed to have proof of work to override other people's drawings.

json { "kind": 33001, "content": "# ff0000", "tags": [ ["d", "100:4224"], ["nonce", "776797", "21"] // proof of work ], ...other fields }

If people want to compete, then we need a way to override other people's pixels. We can do that by having some logic in a strfry relay about overriding kind 33001 events if another event comes with greater POW.

P2P Trading Groups

Idea is from Ravi Patel. Basically the concept is to replace these Telegram groups for doing P2P trades. Will need to utilize WoT. Will expand on it later.

Live Calls

json { "kind": 15000, "content": "", "tags": [ ["server", "https://example.com"] ["protocol", "signal"] ], ...other fields }

We can pick from one of these protocols: signal, simplex, and hypercore (like keet), or others. We may need to add some ID specific to that used protocol in the kind:15000 event, and do a NIP-05 like verification of it on the client side.

Here are the things that we can aim to enable:

• Private contacts
• One on one DMs
• potentially much more privacy preserving than NIP-44 DMs
• we can just use NIP-44 for DMs for those who don't have a kind:15000 event configured, but use the external protocol for those who do
• Group messages
• One on one voice calls
• One on one video calls
• Conference voice calls
• Conference video calls
• Share files via DM or to groups
• Audio texts, photos, videos, and other docs like in WhatsApp
• Expiring "stories" that can be seen only by your contacts or whitelists
• Voice calls with a link that can be shared with others
• Video calls with a link (like Google Meet) that can be shared with others

Maybe we don't need to protocol tag and the URI of the server will provide enough info.

Services on nostr

2 Way Auth

Client visits a URL on browser. Finds npub in meta tag like this:

html <meta name="nostr" content="npub...">`

We can use use a method similar to NIP-42 (Authentication of clients to relays). We can have event with kind:222xx with the other and challenge tags:

json { "kind": 222xx, "tags": [ ["other", <hex pubkey of other party>], ["challenge", <challenge string from the other party>] ], ... }

(Do we need the other tag? Why is the u tag there in NIP-98?) Both parties make authenticate each other this way. Idea borrowed from what I had heard John Carvalho talk about when talking about Slashtags.

We can also use the Authorization: Nostr eyJ... format from NIP-98 (HTTP Auth) to send the tokens in headers when using an API.

Update: This PR by Semisol: NIP-97 Login with Nostr achieves half of what I want. Maybe add the other stuff as a PR that relies on it. The PR needs some reworking based on the feedback provided

Need to think: If on a browser and the client (most probably a browser extension) found out that it's a service provider on nostr from the meta tag, which URL does it consider to be the service endpoint?

Use Cases

When visiting a webpage, you can have a browser extension display you its npub (after authenticating) to make sure that you are on the right page. A service's service endpoint will be posted by it via a kind:100xx event (we can probably just use the kind:0 event with an extra field too), so you can visit a service's endpoint from just having it's npub, you don't have to trust DNS anymore.

You can bookmark services in a similar manner to NIP-51 (Lists). Bookmarks can be kind:1000xx lists, or kind:3000xx sets.

Here is an example set:

json { "kind": 300xx, "tags": [ ["p", "07caba282f76441955b695551c3c5c742e5b9202a3784780f8086fdcdc1da3a9"], ["p", "a55c15f5e41d5aebd236eca5e0142789c5385703f1a7485aa4b38d94fd18dcc4"] ], "content": "TJob1dQrf2ndsmdbeGU+05HT5GMnBSx3fx8QdDY/g3NvCa7klfzgaQCmRZuo1d3WQjHDOjzSY1+MgTK5WjewFFumCc.....TQ==", ...other fields }

We should probably wait till NIP-44 gains more adoption and then use it for encryption instead of using NIP-04 like NIP-51 suggests.

Bots on nostr

This is an extension of services on nostr. (I have seen Fiatjaf mention this idea multiple times, but not sure this is what hea meant) The services can have a standard interface with which users can talk to them.

Commands

These are kind:110xx events created by the service (bot) to list all the commands it responds to.

json { "tags": [ ["c", "balance"], ["c", "imagine"] ] ...other fields }

We can add more data in the future to these commands. Not sure exactly how, but a description, and maybe price etc would be nice.

We can have these command list events be only visible for the service users too. Either using gift wraps and NIP-44 or using NIP-04 for now.

Just like Discord bots, the client can keep a websocket connection open with it too. The simplest thing would be to just use nostr events (DMs) for communication. But if you open a websocket connection with the service endpoint by mutually authenticating each other anyway, then you don't need signed events for authenticating each piece of data to and from the service.

The idea is to also have widgets associated with these bots/services, that push information to you, or give an updated stream of information.

Consider these examples: - A widget from your ISP that shows an updated data balance - An auto expiring reminder from your ISP that you have consumed 50% of your data - A command from text to image service called "/create" that allows you to create pictures, but a sticky widget with the your sats balance that shows your balance decrementing every time you use it - A notification tagged urgent and important from your cloud provider when your production site goes down. Keeps repeating till you acknowledge it - A bitcoin's price widget from npubxyz... that always displays the updated price when you open the app

Collaborative Document Editing

The idea is to enable Google Doc, Figma like applications using nostr identities

See: - GitHub issue: https://github.com/nostr-protocol/nips/issues/929 - fiatjaf's article: https://habla.news/fiatjaf/Zih6ZDW1_63L3QUIaK8BU

Games on nostr

There is a Telegram group created by some other nostriches for discussing this topic: https://t.me/NostrGamedev

My idea is to use JSON schemas to define the rules of 1v1 games. And also have some kinda templates that can display the moves associated with the games, can be just HTML5. I will start with simple games like Rock Paper Scissors and then move on to Tik Tak Toe and then eventually to more complex ones like Chess.

# My Own Apps

• Liphapha: the finanance app using Cashu with a focus on private communcation over nostr
• Nauka: a mobile client for live streams and nests
• Roostr: the everything app? i dunno i just like the name