Presence over replacable events

[fernandolguevara]

thread to start discussing an event related to presence

{
"id": "<event-id>",
"pubkey": "<pub-key>",
"created_at": 1000000000, // last seen at
"kind": undefined, // Replacable Event Kind from 10_000 to 20_000 
"tags": [
    ["status","online|idle|do-not-disturb|offline", "custom-status", /* valid until, optional */<unixtime>],
    ["g", ""] // location, if it is shared
    // ... more tags
],
"content": "{
    ... data, if it is needed ...
}",
}

[barkyq]

It might be nice having prefix searches for things like: "online".

Also perhaps with a primary "relay" you are interacting with (and you could send the status event to multiple relays, but maybe heavier content posted only to the primary relay). Then a client could quickly see who is online and where they are posting to.

[barkyq]

Another possibility... use parameterized replaceable events with d tag equal to the relay url and content equal to some status message ("online," "posting," "disconnected," etc). Let us say kind 30001 for concreteness.

Hopefully some relays would be well-known for relaying status events. (let us call such a relay a "status relay" for the puposes of this comment).

Then if I want to follow "fiatjaf" I can just send a "REQ" to a "status relay" for kind 30001 authored by "fiatjaf". By using limit:N (hopefully ordered by created_at) I would get a unique list of the N most recent relays "fiatjaf" was using (and the time he sent the status). Thus the status relays could also double as a sort of bootstrapping relay (c.f. the discussion in #145).

By keeping the websocket to the "status relay" open, and filtering by authors: [friend1, friend2, ...], one would receive a continuously updating stream of status messages with (presumably) the optimal relay to use when interacting with that "friend".

I have not much to say about the mechanics of how clients would push the status events, and potential privacy concerns, but hopefully there can be some discussion of these topics.

Also, one issue is that it would be tricky to "delete" previous status messages with a d tag for a relay you are no longer using. Although NIP-09 could be used in this case.

[arkin0x]

Regarding privacy, I don't think any responsible client would let a user publish their current location unless it was encrypted in a DM or chat. This means that personal locations should never utilize the g tag.

However, the location tag g is very useful for public transit like busses, public locations like storefronts, and other things that don't put an individual's personal security at risk. And presence could be useful for a business to say they are open, or a bus to say which stop they are going to next.

Just because nostr is ours doesn't mean we shouldn't take privacy seriously. Imagine the CCP using a user's geo presence to drone them automatically. No person's location should ever be unencrypted, and I definitely advocate for emphemeral or replaceable events whenever an encrypted location is used.

[ekzyis]

I have been searching for something like this. My use case is to show if random sessions I am creating with https://github.com/ekzyis/nostr-qrchat are still active/online.