nostr_profiles

NIP Proposal: Simple Nostr Profile System

Motivation:

In the current Nostr ecosystem, user profiles are often overwritten by different applications that maintain their own versions. This lack of synchronization and consistency across apps can lead to outdated or incorrect profile information. A unified, versioned profile system is necessary to ensure that users can maintain a single, authoritative profile that is synced across all devices, apps, and relays, while still allowing for personalization and extensions.

Design Overview:

1. Profiles are stored in <pubkey>.json.

   • Each user’s profile is associated with their public key and stored as a JSON file.

2. The profile payload is your kind=0 parsed JSON.

   • The profile is based on the existing Nostr kind=0 format, which is simple, flexible, and already familiar to the ecosystem.

3. Store the profile in .well-known/nostr/pubkey/ if available.

   • If the user has control over a web server, the profile can be hosted in the .well-known directory for easy access by others.

4. Profiles can also be stored locally in .nostr/pubkey/.

   • This allows for offline or local-only usage, with the ability to sync later.

5. Optionally, new revisions should be stored in Git.

   • Profiles can be versioned using Git, providing a history of changes and the ability to roll back or compare versions.

6. Sign changes in state with your private key.

   • Every profile update should be signed with the user’s private key to ensure authenticity and integrity.

7. Optionally, add an on-chain commitment to sync globally.

   • For extra security or proof-of-ownership, users can commit profile changes to a blockchain, providing a global, immutable sync point.

8. Read from relays to get the latest profiles, and merge.

   • Clients should fetch the latest profile updates from the user’s connected relays and merge any changes intelligently.

9. Push the latest version back to all your relays.

   • Once updates are made, the new version of the profile should be distributed across all relays to ensure consistency.

10. Allow extensibility and links to other items and lists.

• The profile system should be flexible, allowing users to link to other resources (such as lists, contact directories, or other personal data) and extend their profiles with additional fields as needed.

JSON format

The json should either:

• be a single JSON object
• be an array of objects where item[0] is the profile
• other items in the array are reserved for meta data

(c) 2024 Project Sandymount