#

development-bounty

(30 articles)

Nostr Live Audio Spaces: Nostr Notifications/Live Activities

Work must build upon a free open source software (FOSS) project based on JAM Systems as a fork or contribution to this repository: https://github.com/diamsa/jam To satisfy this bounty, there are three types of enhancements wanted. It may be appropriate to break these into smaller/separate bounties. Please reach out to me to coordinate. ## Terms - <room name> is the human readable name or topic of a room - <roomid> refers to the short room name identifier in an audio space that acts as the programmatic reference - <serverfqdn> is the server domain name (e.g. cornychat.com) - <serverid> is a server identifier (e.g. cornychat) ## User Status Notifications - Users should be given an action (button, link, etc) to allow them to quickly set their nostr status - The status should following [NIP-38](https://github.com/nostr-protocol/nips/blob/master/38.md) Users Statuses - This is a kind 30315 event which should be structured as follows ``` { "kind": 30315, "content": "<Talking,Listening> in <roomid> at <serverid>", "tags": [ ["d", "general"], ["r", "https://<serverfqdn>/<path-to-room>"], ["expiration", number-that-is-1-hour-from-now] ], } ``` - The content of `Talking` or `Listening` should be set based on whether the user is on stage or in the audience at the time they choose to publish status - The expiration value can default to 1 hour from now as time in seconds since epoch. - This event should be signed by the user, and may be signed with a browser extension ## Scheduled Events Publishing - In the Room Settings, if a room is being scheduled for a later date and time, the server should pubish a Nostr Event - The server should have its own configurable NSEC. The NSEC should be configurable in the ./deployment/.env file, carried through into docker-compose to the server logic - Scheduled events should prepare Nostr Calendar event [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md#time-based-calendar-event) for an event - The structure for the event should be a time-based event [kind 31923](https://github.com/nostr-protocol/nips/blob/master/38.md). The `d` tag can be set as the &lt;serverid&gt;-&lt;roomid&gt;-&lt;starttimestamp&gt;. - ➤ Tags for the event do not need to include all participants in `p` tags, but should include at least the moderator/owner that set the room settings as a scheduled event - ➤ The value for `location` tag should be set as "online audio space" - ➤ The reference link `r` tag should - ➤ This event should be signed by the server key - ➤ Each time-based event created for a room should be tracked by the server instance in the redis memory store - Two nostr calendars for the room should be created as a calendar event [kind 31924](https://github.com/nostr-protocol/nips/blob/master/52.md#calendar). - ➤ Calendar with `name` "<room name> events" should include all events in the future, as well as those that started in the last hour - ➤ Calendar with `name` "<room name> past events" should be created including all events where the start time is in the past by more than an hour ## Live Activities Publishing - When a room is open, a [Live Event](https://github.com/nostr-protocol/nips/blob/master/53.md#live-event) activity should be created per [NIP-53](https://github.com/nostr-protocol/nips/blob/master/53.md) - A kind 30311 event should be prepared with the following structure ``` { "kind": 30311, "tags": [ ["d", "<serverid>-<roomid>"], ["title", "<Room name>"], ["summary", "<description>"], ["image", "<logo uri from room settings ? server logo uri>"], ["t", "#<serverid>"] ["t", "#<roomid>"] ["audiospace", "<url to room>"], ["starts", "<unix timestamp in seconds>"], ["ends", "<unix timestamp in seconds>"], ["status", "<planned, live, ended>"], ["current_participants", "<number>"], ["total_participants", "<number>"], ["p", "91cf9..4e5ca", "wss://provider1.com/", "Host", "<proof>"], ["p", "14aeb..8dad4", "wss://provider2.com/nostr", "Speaker"], ["p", "612ae..e610f", "ws://provider3.com/ws", "Participant"], ["relays", "wss://one.com", "wss://two.com", ...] ], "content": "", ... } ``` - The `d` tag should be deterministic based on server identifier and room name. This will be referenced in any `a` tags for live chat referencing the room. - The event should be signed by server nsec and published to relays - When room settings are changed, the event should be updated and republished as 30000 series is replaceable events 2023-12-08 - updated to reflect this should build on or fork from https://github.com/diamsa/jam 2023-12-17 - expanded details to reflect this focuses on user status, calendars, and live activities with more guidance

Nostr Live Audio Spaces: Enable Zapping Participants

Work must build upon a free open source software (FOSS) project based on JAM Systems as a fork or contribution to this repository: https://github.com/diamsa/jam To satisfy this bounty To satisfy conditions for this bounty, the following or appropriate variant should be implemented - Either contributions to https://github.com/diamsa/jam, or forked to a publicly accessible repository - Target an individual user within the space/room/nest of participants - If they do not have an npub, cancel and notify initiator - With an npub, lookup the most recent metadata (kind 0) from a set of relays, and parse the lightning address info from any valid lud06 or lud16 data. - If no lightning address can be determined, cancel and notify initiator - With a lightning address, parse and call the LNURL endpoint for payRequest per LUD-06. - If there is no response or error, cancel and notify initiator - Prompt the initiator for the amount of sats to send - Initiator can cancel - Prepare a zap request (kind 9734) to zap the pubkey. A comment could be "Zapping you in {url-to-audio-space}" or something to that effect. Even better, allow for input of a custom comment - Request initiator to sign event - Initiator can cancel - Send to callback to request invoice, using the nostr querystring argument. The value should be the uri encoded result of the json encoded signed event. - If there is no response or error, cancel and notify initiator - Present invoice to user in QR code and text form with convenience copy to clipboard actions 2023-12-08 - updated to reflect this should build on or fork from https://github.com/diamsa/jam - updated to reflect the signed event should be uri encoded when passed as nostr querystring argument when calling the callback

Nostr Nests

**Nostr Nests Background:** Social audio is important because it provides a new and engaging way for people to connect, learn, share their stories, and build their communities. It is also a valuable tool for businesses and organizations to reach their audiences and build relationships. With this in mind, I knew that having an audio space outside of Twitter Spaces would be vital for nostr adoption, and set out to make this happen in January 2022. The current [Nostr Nests](https://nostrnests.com) is a fork of the open source Jam System project, with custom user interface, Nostr npub verification, and several enhancements such as account restoration, discovery, and a minimal API. It served as a great starting point for a Nostr audio space, providing users all over the world with a platform for daily shows, weekly podcasts, and places for Nostriches to meetup and chat live with one another. It’s a great success. However, it’s not a complete success and it will never be in its current form. It has always been a dream of mine for Nostr Nests to be a full blown Nostr client, instead of loosely integrating Nostr into Jam's existing account verification system. My dream and vision for Nests is for anyone to be able to host a Nest on their own server or infrastructure and use Nostr NIP-53 Live Activities to publish their Nest to their Nostr relays, allowing anyone with a compatible client to discover and join their Nest. This is similar to how Zap.stream works on Snort and Amethyst clients. This functionality also helps decentralize Nostr Nests, so not one entity runs the audio backend. It is my hope to provide easy access to the open source code and installation instructions on https://nostrnests.org for all. Several months ago, the groundwork for building Nests as a proper Nostr client began, but has since stopped. Even with open sourcing the project and seeking developer help, these efforts have failed. This bounty is another attempt at getting this project off of the ground and allowing those that use Nostr Nests on a daily basis to pledge their sats to help fund this project. As my vision for Nostr Nests is a very large project, this project will be split into two bounties. The first bounty will aim to have the rewrite of Nostr Nests be feature compatible with the Jam System forked version with several quality of life enhancements. The second bounty aims to cover application customizations, feature additions, and individual Nest customizations (icons, badges, emojis, etc.) to provide Nest owners with tools to build their community and reward their participants and listeners. --- **Initial Nostr Nests Scope:** (The word Room will be used here to be less confusing. A room is an individual Nest.) **Room Presence** * Raising/lowering hand to speak * Reactions * Zaps * Exiting stage **Room Management** * Removing and adding people to stage and moderators * Changing room information * Handling stage exit logic **Room Discovery** * Allowing users to discover Nests * NIP-53 in clients * Homepage **Room Chat** * NIP-28 * Individual Nest chats * Reactions to comments * Zaps to comments * Replies **Design** * Design UI elements for new components such as an improved homepage, Nest discovery, etc. * Must be compatible with the existing design. **Audio** * General Room audio * Backend and frontend **Groundwork:** * The groundwork for Nests has begun and is located on our private Git * https://git.semisol.dev/NostrPlebs/nests/ --- Nests users: Please pledge your sat donation to help get this project built. Developers: Please reach out if you have any questions.

Make Nostr Relay that applies limits based on proximity to a group of accounts

I want to **run a relay** financed by a tiny percentage of its users and strongly believe in the following being a way to align incentives for all clients and relay operators: For this bounty, the minimum requirement for the resulting relay is: * relay is as efficient or better than [strfry](https://github.com/hoytech/strfry) at supported nips, synchronization between instances and handling concurrent connections * nip42 support * all read and write operations are metered per connected pubkey: milliseconds spent on queries, query count, events sent, event kBs sent, etc. (If Alice pushes Bob's events, it gets tallied to her pubkey - the one authenticated via nip42) * allow managing group of primary (TIER 0 or T0) users via API * secondary users are those followed by T0 users etc. * define limits depending on follows distance to primary users, using five tiers: 0 = primary users, 1 = follows, 2 = follows of follows, 3 = follows of follows of follows, inf = all the other pubkeys * allow configuring hourly, daily and monthly limits per tier and metered aspect. **This bounty was created with the goal of actually running a relay with this feature and will not be awarded for a proof of concept that is not a fully functional and performant relay. Strfry is "good enough". If you want to implement the proposed feature in a different relay, please reach out to discuss first.** This bounty was offered in other places before: * [github.com/hoytech/strfry](https://github.com/hoytech/strfry/issues/17) * [bountsr.org](https://bountsr.org/relay-with-wot-based-limits/)