NIP-XX --- Multilingual External Identities in Profiles

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 (opens in a new tab).

draft optional

depends:39

1. Motivation

The purpose of this NIP is to provide a multilingual alternative to the proofs of NIP-39 (opens in a new tab).

2. Short Description

This NIP aims to reduce the hurdles non-English speakers need to enjoy the full feature-set provided by NOSTR.

Specifically, for the implementation of the "i" tag validation, users need to commit to a public key via a public message on an external site. Having an English message appear in an otherwise non-English feed can be jarring, and the purpose of this NIP is to make it less so.

3. Overview

This document is organized as follows: first we introduce the new Multilingual "i" Tag, finally, we provide som Predefined Translations to be used.

4. Multilingual "i" Tag

A multilingual "i" tag is simply a regular "i" tag as defined in NIP-39 (opens in a new tab), but instead of consisting solely of the tag itself, a "platform / identity" string, and a proof string, an additional string representing a language MAY be added as well at the very end, as an additional tag parameter, we'll call this parameter the "i" tag's language tag. This new string MUST be a valid RFC 4646 (opens in a new tab) language tag (these are the same identifiers used for the HTTP Accept-Language headers).

A missing language tag MUST be interpreted as being equal to "en" (this is stipulated in order to provide backwards compatibility with NIP-39 (opens in a new tab) "i" tags).

The presence of a language tag indicates to clients that the expected text to be found in the external site referred to in the proof of a NIP-39 (opens in a new tab) "i" should be selected according to its value. In the next section, predefined translations for some of these language tags are defined.

4.1. Predefined Translations

NOTE: this list is non-exhaustive and can be extended in future NIPs.

Taken (quite arbitrarily) from "Wikipedia page views by language" (opens in a new tab). Translations were generated by Google Translate, with no oversight whatsoever.

5. Technical Notes

Spoken languages are not necessarily easy to get right from a technological perspective. In particular, non-latin alphabets, diacritics, and right-to-left direction, tend to be progressively harder to get right.

In this NIP, we took the following approaches:

1. All characters are specified as Unicode codepoints.
2. Said codepoints are in pre-composed form.
3. Right-to-left and Left-to-right are signalled via LEFT-TO-RIGHT ISOLATE, RIGHT-TO-LEFT ISOLATE, and POP DIRECTIONAL ISOLATE codepoints.

The rationale behind these is:

1. We could have specified this as UTF-8 codes just as well, but this would have left conversion to other encodings under-specified; specifying Unicode codepoints removes all ambiguity.
2. Different systems default to different compositional forms, specifying pre-composed form removes ambiguities; although only the pre-composed forms are strictly required, clients are encouraged to apply Normalization Form KC (NFKC) (opens in a new tab) to the proof text.
3. All texts are surrounded by directional isolate markers (opens in a new tab), this is so that they can be embedded anywhere irrespective of context and look precisely as prescribed; furthermore, internal directional changes are dealt with via directional isolate markers themselves.