Nostr-odyssey

Odyssey is a new nostr-compatible protocol which functions as an extension to nostr. Odyssey clients can interact with nostr relays and vice-versa. Odyssey events can be stored on nostr relays.

Odyssey is not meant to compete with nostr. Odyssey depends on nostr; nostr is the foundation of odyssey.

You can think of odyssey as a testing ground for new nostr features which may eventually move into nostr. Or you can think of it as a set of features that nostr does not wish to adopt, but which other community members do wish to adopt. Either way works, and which interpretation turns out to be more correct will only be determined by future actions.

Users should consider odyssey experimental. Use at your own risk.

CHANGES TO BE APPLIED

The following changes are in flux for this:

1. Swtich to a binary protocol. JSON is code with horrible escape sequence rules and canonicalization shit. Use Big Endian integer formats.
2. State some rules
   1. Components (clients and servers) will be removed from the list of standard complying components if they do something that violates the standard. The community should ostracize such clients and servers, because if they are allowed to persist and become popular, they can embrace-extend-extinguish this protocol.
   2. Changes must always be backwards-compatible. New features can be added, and signalling of available features can be added or extended, but all old features must continue to work or else the component is in violation of this standard.
3. NIP-65 model from the outset
4. Possibly move away from bech32 (are people typing these?) or find/define a very clear impl standard for it
5. No NIP-04, only advertise a protocol and address/endpoint where you can be contacted.
6. Means of hiding relays from the CCP (probably not possible)
7. Timestamps in unixtime, except as TAI to avoid leapsecond crap
8. Who you follow (contact lists) are suggested to be private things
9. EOSE and AUTH from the outset. For AUTH, think about challenge-response and also relays hiding themselves from clients they don't yet know. The challenge maybe should be in the websocket header, perhaps disguised as some other kind of header (for issue 6).

Motivation for Odyssey

Odyssey was created to free the author from the tedium of standards negotiation to instead focus on code development and the fleshing out of new features, without requiring those features to be added to nostr itself first. It is a bit of a testbed, a playground, and a laboratory, a place where the author can take more risks and forge ahead more quickly.

The standards negotation process is important. But it belongs in nostr. Odyssey does not have a standards negotiation process because that would defeat the experimental purpose of odyssey which is to be a juggernaut of new potential features, not encumbered by a tedius standards negotiation process. Users of odyssey-enabled software should consider odyssey experimental. Use at your own risk.

Additionally, nostr has a few problems which are hard to fix given the values held by its creator.

There is no versioning or feature negotiation

The creator of nostr believes "version numbers and other cheap ways to introduce backwards-incompatible changes are pernicious to any open protocol." Yet they have implemented a out-of-band form of feature negotiation in NIP-11, and rely on it in NIP 12, 15, 16 and 22 in a "SHOULD" kind of way.

This author's take is that backwards-incompatible features are sometimes necessary. Not everything can be predicted ahead of time. Shit happens, and in the real world we need to be prepared for how to handle such situations. Versioning and feature negotiation allow us to make backwards-incompatible changes actually compatible again, because the older software won't be confronted with the newer incompatible changes if its peer detects it wouldn't understand them.

There is no way to add new types of filters without breaking something

New kinds of filters cannot be added to the relays. Even though NIP-12 does this, it does so in a way that kind-of leaves a mess.

The original specification did not specify what a relay should do if it finds new filters it doesn't understand. This is quite problematic:

• If it ignores them, it may return far too much data. Consider the case where the client supplied ONLY the filter field that was ignored.
• If it rejects the request without informing the client, the client may either continue to wait forever, or presume no events matched that filter. But we can't require an error response from the relay because NIP-20 is optional.

Why Formalize

You might wonder why the author should formalize a protocol that is primarily just the author's exploration.

1. It jogs the memory. The author's memory is not good.
2. It allows other developers to leverage the features of odyssey should they find them compelling.
3. It communicates back to fiatjaf and the NIPsters ideas that they could choose to formalize into future nostr NIPs.

Basis

Odyssey is currently based on nostr which is defined in NIP files here. Each is incorporated in turn by reference below.

Nostr is a very good protocol. No other social media protocol is anywhere close to having made all the right decisions in the following respects:

• It does not require clients to trust servers (relays)
• It provides censorship resistance via redundancy as well as cryptography
• People can easily move away from servers that mistreat them without loss of service
• Users are fully in control of their own identity via cryptography
• There is very little unnecessary complexity (e.g. data schemas, the semantic web, blockchain tie-ins, or other ill-conceived complexity)
• And yet it's design enables all kinds of complex use cases built on top of the protocol.
• It uses a client-server model, which is necessary as many clients cannot listen to an Internet exposed port (p2p is plagued with this problem)
• It uses website ports so as not to be blocked by firewalls
• It offers a publish-and-subscribe model, which avoids polling
• It offers a way for people using existing systems (e.g. DNS) to find people on nostr

Restrictions to Changes from Nostr

Odyssey intends to preserve the nostr event structure such that odyssey messages may be handled and stored in relays which are not odyssey-aware.

Odyssey will attempt to not introduce any feature that could be expected to collide with a potential future change to nostr. For example, odyssey will not define new event kinds because the nostr standard may define a new event kind with the same number causing a collision. This is also true of single-letter tags.

Changes to base protocol

These changes are currently defined in terms of differences from the nostr protocol.

NIP-01

NIP-01 is incorporated here by reference and remains mandatory, with the following additions and modifications:

Websocket Subprotocol

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, mandatory

The websocket connection from client to relay MUST include a Sec-WebSocket-Protocol HTTP header with the value of nostr-odyssey-experimental. If no such header is found, relays SHOULD presume the client is not odyssey-aware and MAY serve the client as a nostr client.

Relays MUST return that same header in their response. If they don't, clients SHOULD presume they are not odyssey-aware relays and MAY continue to attempt to operate with them under the nostr protocol.

Should nostr ever introduce a value for this header, clients MAY provide both values to a relay, and relays MAY choose to offer either protocol.

We reserve the subprotocol nostr-odyssey in case odyssey becomes a non-experimental protocol beyond nostr proper.

Additional filter fields

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, mandatory

The <filter> structure gets two more optional fields

{
  "seen_since": <a timestamp, events must have been received by this relay at or later than this to pass>,
  "seen_until": <a timestamp, events must have been received by this relay before this to pass>
}

While the since and until filters operate on the event.created_at timestamp, these operate on the timestamp given to the events when they arrived at the filter.

Unrecognized Filter Fields

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, mandatory

Relays which encounter fields within the <filters> structure that they don't understand MUST respond with an OK message (see NIP-20) with a value of false and a prefix of unknown-filter:, and then in order the name of the subscription and then the name of the fields that were unknown.

Feature Negotiation

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, mandatory

There exists an additional client-to-relay and identical relay-to-client message in the form:

["FEATURES", <feature1>, <feature2>, ... ]

where the client discloses to the relay the protocol features it wishes to use. Clients MAY send this message to negotiate (likely backwards-incompatible) features that were not present in the base protocol. If clients do not send this message, relays MUST only use base protocol messaging with that client.

Relays MUST respond with FEATURES message (the client will be waiting for it). Relays MUST only supply features that the client supplied in their message, and which the relay also supports. That is, the feature set that the relay responds with must be a subset (but not necessarily a proper subset) of the features requested by the client.

Relays MUST not initiate feature negotiation.

When clients receive such a list of features from a relay, they MUST then operate the protocol under those features going forward, as must the relay.

Prior to feature negotiation, peers MUST not use any features that require negotiation.

Positional "e" tags are no longer recognized

See NIP-10 for details. Odyssey no longer recognizes positional "e" tags.

NIP-02

NIP-02 is incorporated here by reference and remains optional.

NIP-03

NIP-03 is incorporated here by reference and remains optional.

NIP-04

NIP-04 is incorporated here by reference and remains optional. However its use is discouraged. It leaks metadata and has a known cryptography weakness.

NIP-05

NIP-05 is incorporated here by reference and remains optional.

NIP-06

NIP-06 is incorporated here by reference and remains optional. Although this author does not understand what it is talking about or how it is to be applied.

NIP-07

NIP-07 is incorporated here by reference and remains optional.

NIP-08

NIP-08 is incorporated here by reference and remains optional. However, all the MUSTs are transposed into SHOULDs.

NIP-09

NIP-09 is incorporated here by reference and remains optional.

NIP-10

NIP-10 is incorporated here by reference but becomes mandatory. Positional "e" tags are no longer recognized in Odyssey, only marked "e" tags.

NIP-11

NIP-11 is incorporated here by reference and remains optional. This remains to assist nostr-only clients. nostr-odyssey clients SHOULD not relay on this but instead use feature negotiation.

NIP-12

NIP-12 is incorporated here by reference but becomes mandatory so that there are no relays who ignore these new tags and reply with too many events.

NIP-13

NIP-13 is incorporated here by reference and remains optional.

NIP-14

NIP-14 is incorporated here by reference and remains optional.

NIP-15

NIP-15 is incorporated here by reference but becomes mandatory.

NIP-16

NIP-16 is incorporated here by reference but becomes mandatory.

NIP-20

NIP-20 is incorporated here by reference but becomes mandatory.

NIP-22

NIP-22 is incorporated here by reference and remains optional. It is suggested that relays accept events created in the reasonable past (but not before nostr was conceived of) so that people can move their old events to new relays.

NIP-25

NIP-25 is incorporated here by reference and remains optional.

NIP-26

NIP-26 is incorporated here by reference and remains optional.

NIP-28

NIP-28 is incorporated here by reference and remains optional.

NIP-35

NIP-35 is incorporated here by reference and remains optional.

Beyond changes to current NIPs

Odyssey Event Kind

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, mandatory

A new tag called odyssey-event-kind with one string parameter adds a odyssey-specific event kind in a way that is backwards compatible with nostr, and that odyssey-aware clients and relays MUST consider to supersede the base "kind" parameter.

Odyssey-aware relays MUST allow searching on this tag as if it were a single-letter tag.

This tag MUST not be present in events which are to be considered a nostr event kind.

We use strings instead of numbers as they are comprehensible at a glance to developers.

Odyssey Event Kind - "plain text"

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, mandatory

A new odyssey-event-kind of plain text shall indicate a literal UTF-8 encoded text note which is unmolested by any kind of interpretation such as NIP-08 mentions, URL detection/replacement, etc and which SHOULD be displayed without alteration or interpretation by clients.

The event.kind field for ["odyssey-event-kind": "plain text"] MUST be set to 1 for backwards compatibility.

Odyssey Relay URLs

Status: draft, not-yet-client-implemented, not-yet-relay-implemented, optional

Odyssey relay URLs SHOULD not be served from the base of a domain, but from the well-known path /nostr-odyssey, for example wss://nostr.example.com/nostr-odyssey

Future Extensions

The following kinds of future extensions are expected

• Extensible signature scheme, so that if the current signature scheme is later determined to have a security weakness, there is a method in place for switching to a stronger scheme.
• Message chaining, so that censorship of some message can easily be detected.
• Key rollover, so people can move from a weakly secured key to a stronger one.
• Advertisement of a P2P service, so two clients can go off separately and have a private encrypted chat without relays collecting metadata on them.
• Storing your private key (well encrypted) as well as other client setting information in an event on relays, so you can use any client anywhere without needing some out-of-band means of moving your data across.
• Keep-for tag, authors requesting relays keep the event for the stated duration. Relays don't have to honor, and should watch for overuse. I would set to 1 month for most of my text notes, maybe 3 years for my blog posts.
• Upvotes/Downvotes should be able to have reasons. I prefer a client setting where downvotes without reasons are not counted. Downvotes are emotionally taxing mainly because the author doesn't understand why he/she is getting downvoted, hence the benefit of reasons.
• Can mark a reply as final, meaning you do not wish further replies and are muting further replies.
• A way to edit posts, An event that replaces the prior event.
• Moderation tagging of other people's posts: spam, hate speech, harassment, nsfw, or the inverses (not hate speech, not spam, etc). Clients can then be configured to trust certain other people's judgements at various levels of trust.
• URL scheme for nostr so nostr links can be posted on Twitter and make those guys curious, probably nostr://relay.example.com/{id}
• Recovery requests: where someone can ask for an event that the relay does not have to be uploaded by any good-samaritan client who does have it. Generally people would do recovery requests on relays different from the one that deleted/banned the post.

Why the name Odyssey?

Because this is an adventure, an exploration into new features and new ways of solving problems.