![](https://image.nostr.build/254e6f060b6bdf678572636a900a12af5ec74ddfa55c74669c9894f431b0b7f7.gif)
@ Vic :Cacodemon: :doomguy:
2023-12-17 18:09:59
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 <serverid>-<roomid>-<starttimestamp>.
- ➤ 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