What is Nostr?
nathan_day / Nathan Day
npub1cn6…wt8a
2024-09-11 13:59:37

Cryptography, the Commons and Proof of Place

TL;DR

Best viewed on either YakiHonne or Highlighter.

This article explores the links between public, community-driven data sources (such as OpenStreetMap) and private, cryptographically-owned data found on networks such as Nostr.

The following concepts are explored:

  1. Attestations: Users signalling to their social graph that they believe something to be true by publishing Attestations. These social proofs act as a decentralised verification system that leverages your web-of-trust.
  2. Proof of Place: An oracle-based system where physical letters are sent to real-world locations, confirming the corresponding digital ownership via cryptographic proofs. This binds physical locations in meatspace with their digital representations in the Nostrverse.
  3. Check-ins: Foursquare-style check-ins that can be verified using attestations from place owners, ensuring authenticity. This approach uses web-of-trust to validate check-ins and location ownership over time.

The goal is to leverage cryptographic ownership where necessary while preserving the open, collaborative nature of public data systems.

Open Data in a public commons has a place and should not be thrown out with the Web 2.0 bathwater.

Cognitive Dissonance

Ever since discovering Nostr in August of 2022 I’ve been grappling with how BTC Map - a project that helps bitcoiners find places to spend sats - should most appropriately use this new protocol.

I am assuming, dear reader, that you are somewhat familiar with Nostr - a relatively new protocol for decentralised identity and communication. If you don’t know your nsec from your npub, please take some time to read these excellent posts: Nostr is Identity for the Internet and The Power of Nostr by @max and @lyn, respectively. Nostr is so much more than a short-form social media replacement.

The social features (check-ins, reviews, etc.) that Nostr unlocks for BTC Map are clear and exciting - all your silos are indeed broken - however, something fundamental has been bothering me for a while and I think it comes down to data ownership.

For those unfamiliar, BTC Map uses OpenStreetMap (OSM) as its main geographic database. OSM is centred on the concept of a commons of objectively verifiable data that is maintained by a global community of volunteer editors; a Wikipedia for maps. There is no data ownership; the data is free (as in freedom) and anyone can edit anything. It is the data equivalent of FOSS (Free and Open Source Software) - FOSD if you will, but more commonly referred to as Open Data.

In contrast, Notes and Other Stuff on Nostr (Places in this cartographic context) are explicitly owned by the controller of the private key. These notes are free to propagate, but they are owned.

How do we reconcile the decentralised nature of Nostr, where data is cryptographically owned by individuals, with the community-managed data commons of OpenStreetMap, where no one owns the data?

Self-sovereign Identity

Before I address this coexistence question, I want to talk a little about identity as it pertains to ownership. If something is to be owned, it has to be owned by someone or something - an identity.

All identities that are not self-sovereign are, by definition, leased to you by a 3rd party. You rent your Facebook identity from Meta in exchange for your data. You rent your web domain from your DNS provider in exchange for your money.

Taken to the extreme, you rent your passport from your Government in exchange for your compliance. You are you at the pleasure of others. Where Bitcoin separates money from the state; Nostr separates identity from the state.

Or, as @nvk said recently: “Don’t build your house on someone else’s land.”.

While we’ve had the tools for self-sovereign digital identity for decades (think PGP keys or WebAuthN), we haven’t had the necessary social use cases nor the corresponding social graph to elevate these identities to the mainstream. Nostr fixes this.

Nostr is PGP for the masses and will take cryptographic identities mainstream.

Full NOSTARD?

Returning to the coexistence question: the data on OpenStreetMap isn’t directly owned by anyone, even though the physical entities the data represents might be privately owned. OSM is a data commons.

We can objectively agree on the location of a tree or a fire hydrant without needing permission to observe and record it. Sure, you could place a tree ‘on Nostr’, but why should you? Just because something can be ‘on Nostr’ doesn’t mean it should be.

There might be a dystopian future where we can’t agree on what a tree is nor where it’s located, but I hope we never get there. It’s at this point we’ll need a Wikifreedia variant of OpenStreetMap.

While integrating Nostr identities into OpenStreetMap would be valuable, the current OSM infrastructure, tools, and community already provide substantial benefits in managing this data commons without needing to go NOSTR-native - there’s no need to go Full NOSTARD. H/T to @princeySOV for the original meme.

So, how do we appropriately blend cryptographically owned data with the commons?

If a location is owned in meatspace and it’s useful to signal that ownership, it should also be owned in cyberspace. Our efforts should therefore focus on entities like businesses, while allowing the commons to manage public data for as long as it can successfully mitigate the tragedy of the commons.

The remainder of this article explores how we can:

  1. Verify ownership of a physical place in the real world;
  2. Link that ownership to the corresponding digital place in cyberspace.

As a side note, I don’t see private key custodianship - or, even worse, permissioned use of Places signed by another identity’s key - as any more viable than the rented identities of Web 2.0.

And as we all know, the Second Law of Infodynamics (no citation!) states that:

“The total amount of sensitive information leaked or exposed will always increase over time.”

This especially holds true if that data is centralised.

Not your keys, not your notes. Not your keys, not your identity.

Places and Web-of-Trust

@Arkinox has been leading the charge on the Places NIP, introducing Nostr notes (kind 37515) that represent physical locations. The draft is well-crafted, with bonus points for linking back to OSM (and other location repositories) via NIP-73 - External Content IDs (championed by @oscar of @fountain).

However, as Nostr is permissionless, authenticity poses a challenge. Just because someone claims to own a physical location on the Internet doesn’t necessarily mean they have ownership or control of that location in the real world.

Ultimately, this problem can only be solved in a decentralised way by using Web-of-Trust - using your social graph and the perspectives of trusted peers to inform your own perspective. In the context of Places, this requires your network to form a view on which digital identity (public key / npub) is truly the owner of a physical place like your local coffee shop.

This requires users to:

  1. Verify the owner of a Place in cyberspace is the owner of a place in meatspace.
  2. Signal this verification to their social graph.

Let’s look at the latter idea first with the concept of Attestations …

Attestations

A way to signal to your social graph that you believe something to be true (or false for that matter) would be by publishing an Attestation note. An Attestation note would signify to your social graph that you think something is either true or false.

Imagine you’re a regular at a local coffee shop. You publish an Attestation that says the shop is real and the owner behind the Nostr public key is who they claim to be. Your friends trust you, so they start trusting the shop’s digital identity too.

However, attestations applied to Places are just a single use case. The attestation concept could be more widely applied across Nostr in a variety of ways (key rotation, identity linking, etc).

Here is a recent example from @lyn that would carry more signal if it were an Attestation:

Parallels can be drawn between Attestations and transaction confirmations on the Bitcoin timechain; however, their importance to you would be weighted by clients and/or Data Vending Machines in accordance with:

  1. Your social graph;
  2. The type or subject of the content being attested and by whom;
  3. Your personal preferences.

They could also have a validity duration to be temporally bound, which would be particularly useful in the case of Places.

NIP-25 (Reactions) do allow for users to up/downvote notes with optional content (e.g., emojis) and could work for Attestations, but I think we need something less ambiguous and more definitive. ‘This is true’ resonates more strongly than ‘I like this.’.

There are similar concepts in the Web 3 / Web 5 world such as Verified Credentials by tdb; however, Nostr is the Web 3 now and so wen Attestation NIP?

That said, I have seen @utxo has been exploring ‘smart contracts’ on nostr and Attestations may just be a relatively ‘dumb’ subset of the wider concept Nostr-native scripting combined with web-of-trust.

Proof of Place

Attestations handle the signalling of your truth, but what about the initial verification itself?

We already coved how this ultimately has to be derived from your social graph, but what if there was a way to help bootstrap this web-of-trust through the use of oracles? For those unfamiliar with oracles in the digital realm, they are simply trusted purveyors of truth.

Introducing Proof of Place, an out–of-band process where an oracle, such as BTC Map, would mail - yes mail a physical letter - a shared secret to the physical location being claimed in cyberspace. This shared secret would be locked to the public key (npub) making the claim, which, if unlocked, would prove that the associated private key (nsec) has physical access to the location in meatspace.

Proof of Place is really nothing more than a weighted Attestation. In a web-of-trust Nostrverse, an oracle is simply a npub (say BTC Map) that you weigh heavily for its opinion on a given topic (say Places).

In the Bitcoin world, Proof of Work anchors digital scarcity in cyberspace to physical scarcity (energy and time) in meatspace and as @Gigi says in PoW is Essential:

“A failure to understand Proof of Work, is a failure to understand Bitcoin.”

In the Nostrverse, Proof of Place helps bridge the digital and physical worlds.

@Gigi also observes in Memes vs The World that:

“In Bitcoin, the map is the territory. We can infer everything we care about by looking at the map alone.”

This isn’t true for Nostr.

In the Nostrverse, the map IS NOT the territory. However, Proof of Place enables us to send cryptographic drones down into the physical territory to help us interpret our digital maps. 🤯

Check-ins

Although not a draft NIP yet, @Arkinox has also been exploring the familiar concept of Foursquare-style Check-ins on Nostr (with kind 13811 notes).

For the uninitiated, Check-ins are simply notes that signal the publisher is at a given location. These locations could be Places (in the Nostr sense) or any other given digital representation of a location for that matter (such as OSM elements) if NIP-73 - External Content IDs are used.

Of course, not everyone will be a Check-in enjoyooor as the concept will not sit well with some people’s threat models and OpSec practices.

Bringing Check-ins to Nostr is possible (as @sebastix capably shows here), but they suffer the same authenticity issues as Places. Just because I say I’m at a given location doesn’t mean that I am.

Back in the Web 2.0 days, Foursquare mitigated this by relying on the GPS position of the phone running their app, but this is of course spoofable.

How should we approach Check-in verifiability in the Nostrverse? Well, just like with Places, we can use Attestations and WoT. In the context of Check-ins, an Attestation from the identity (npub) of the Place being checked-in to would be a particularly strong signal. An NFC device could be placed in a coffee shop and attest to check-ins without requiring the owner to manually intervene - I’m sure @blackcoffee and @Ben Arc could hack something together over a weekend!

Check-ins could also be used as a signal for bonafide Place ownership over time.

Summary: Trust Your Bros

So, to recap, we have:

Places: Digital representations of physical locations on Nostr.

Check-ins: Users signalling their presence at a location.

Attestations: Verifiable social proofs used to confirm ownership or the truth of a claim.

You can visualise how these three concepts combine in the diagram below:

And, as always, top right trumps bottom left! We have:

Level 0 - Trust Me Bro: Anyone can check-in anywhere. The Place might not exist or might be impersonating the real place in meatspace. The person behind the npub may not have even been there at all.

Level 1 - Definitely Maybe Somewhere: This category covers the middleground of ‘Maybe at a Place’ and ‘Definitely Somewhere’. In these examples, you are either self-certifying that you have checked-in at an Attested Place or you are having others attest that you have checked-in at a Place that might not even exist IRL.

Level 2 - Trust Your Bros: An Attested Check-in at an Attested Place. Your individual level of trust would be a function of the number of Attestations and how you weigh them within your own social graph.

Perhaps the gold standard (or should that be the Bitcoin standard?) would be a Check-in attested by the owner of the Place, which in itself was attested by BTC Map?

Or perhaps not. Ultimately, it’s the users responsibility to determine what they trust by forming their own perspective within the Nostrverse powered by web-of-trust algorithms they control. ‘Trust Me Bro’ or ‘Trust Your Bros’ - you decide.

As we navigate the frontier of cryptographic ownership and decentralised data commons, it’s up to us to find the balance between preserving the Open Data commons and embracing self-sovereign digital identities.

Thanks

With thanks to Arkinox, Avi, Ben Gunn, Kieran, Blackcoffee, Sebastix, Tomek, Calle, Short Fiat, Ben Weeks and Bitcoms for helping shape my thoughts and refine content, whether you know it or not!

Author Public Key
npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a