@ c4f5e7a7:8856cac7

Best viewed on Habla, YakiHonne or Highlighter.

TL;DR

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.".

https://i.nostr.build/xpcCSkDg3uVw0yku.png

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.

https://i.nostr.build/s3So2JVAqoY4E1dI.png

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.

https://i.nostr.build/ot9jtM5cZtDHNKWc.png

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 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:

https://i.nostr.build/lZAXOEwvRIghgFY4.png

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.’.

https://i.nostr.build/s8NIG2kXzUCLcoax.jpg

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?

https://i.nostr.build/Cb047NWyHdJ7h5Ka.jpg

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 covered 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 physically mail- a shared secret to the address of the 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.

One way of doing this would be to mint a 1 sat cashu ecash token locked to the npub of the claimant and mail it to them. If they are able to redeem the token then they have cryptographically proven that they have physical access to the location.

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."

https://i.nostr.build/dOnpxfI4u7EL2v4e.png

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:

https://i.nostr.build/Uv2Jhx5BBfA51y0K.jpg

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 middle-ground 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.

https://i.nostr.build/HtLAiJH1uQSTmdxf.jpg

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, 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!

@ 09fbf8f3:fa3d60f0

由于gmail在中国被防火墙拦截了，无法打开，不想错过邮件通知。

通过自建ntfy接受gmail邮件通知。 怎么自建ntfy，后面再写。

---

2024年08月13日更新：

修改不通过添加邮件标签来标记已经发送的通知，通过Google Sheets来记录已经发送的通知。

为了不让Google Sheets文档的内容很多，导致文件变大，用脚本自动清理一个星期以前的数据。

---

准备工具

• Ntfy服务
• Google Script
• Google Sheets

操作步骤

1. 在Ntfy后台账号，设置访问令牌。
2. 添加订阅主题。
3. 进入Google Sheets创建一个表格.记住id，如下图：
4. 进入Google Script创建项目。填入以下代码（注意填入之前的ntfy地址和令牌）：

```javascript function checkEmail() { var sheetId = "你的Google Sheets id"; // 替换为你的 Google Sheets ID var sheet = SpreadsheetApp.openById(sheetId).getActiveSheet();

// 清理一星期以前的数据 cleanOldData(sheet, 7 * 24 * 60); // 保留7天（即一周）内的数据

var sentEmails = getSentEmails(sheet);

var threads = GmailApp.search('is:unread'); Logger.log("Found threads: " + threads.length);

if (threads.length === 0) return;

threads.forEach(function(thread) { var threadId = thread.getId();

if (!sentEmails.includes(threadId)) {
  thread.getMessages().forEach(sendNtfyNotification);
  recordSentEmail(sheet, threadId);
}

}); }

function sendNtfyNotification(email) { if (!email) { Logger.log("Email object is undefined or null."); return; }

var message = `发件人: ${email.getFrom() || "未知发件人"} 主题: ${email.getSubject() || "无主题"}

内容: ${email.getPlainBody() || "无内容"}`;

var url = "https://你的ntfy地址/Gmail"; var options = { method: "post", payload: message, headers: { Authorization: "Bearer Ntfy的令牌" }, muteHttpExceptions: true };

try { var response = UrlFetchApp.fetch(url, options); Logger.log("Response: " + response.getContentText()); } catch (e) { Logger.log("Error: " + e.message); } }

function getSentEmails(sheet) { var data = sheet.getDataRange().getValues(); return data.map(row => row[0]); // Assuming email IDs are stored in the first column }

function recordSentEmail(sheet, threadId) { sheet.appendRow([threadId, new Date()]); }

function cleanOldData(sheet, minutes) { var now = new Date(); var thresholdDate = new Date(now.getTime() - minutes * 60 * 1000); // 获取X分钟前的时间

var data = sheet.getDataRange().getValues(); var rowsToDelete = [];

data.forEach(function(row, index) { var date = new Date(row[1]); // 假设日期保存在第二列 if (date < thresholdDate) { rowsToDelete.push(index + 1); // 存储要删除的行号 } });

// 逆序删除（从最后一行开始删除，以避免行号改变） rowsToDelete.reverse().forEach(function(row) { sheet.deleteRow(row); }); }

```

4.Goole Script需要添加gmail服务，如图：

5.Google Script是有限制的不能频繁调用，可以设置五分钟调用一次。如图：

结尾

本人不会代码，以上代码都是通过chatgpt生成的。经过多次修改，刚开始会一直发送通知，后面修改后将已发送的通知放到一个“通知”的标签里。后续不会再次发送通知。

如需要发送通知后自动标记已读，可以把代码复制到chatgpt给你写。

效果预览：

@ 7460b7fd:4fc4e74b

请看2014年王兴的一场思维碰撞，视频27分钟开始

最后，一个当时无法解决的点：丢失

@ 3bf0c63f:aefa459d

Nostr is not decentralized nor censorship-resistant

Peter Todd has been saying this for a long time and all the time I've been thinking he is misunderstanding everything, but I guess a more charitable interpretation is that he is right.

Nostr today is indeed centralized.

Yesterday I published two harmless notes with the exact same content at the same time. In two minutes the notes had a noticeable difference in responses:

The top one was published to wss://nostr.wine, wss://nos.lol, wss://pyramid.fiatjaf.com. The second was published to the relay where I generally publish all my notes to, wss://pyramid.fiatjaf.com, and that is announced on my NIP-05 file and on my NIP-65 relay list.

A few minutes later I published that screenshot again in two identical notes to the same sets of relays, asking if people understood the implications. The difference in quantity of responses can still be seen today:

These results are skewed now by the fact that the two notes got rebroadcasted to multiple relays after some time, but the fundamental point remains.

What happened was that a huge lot more of people saw the first note compared to the second, and if Nostr was really censorship-resistant that shouldn't have happened at all.

Some people implied in the comments, with an air of obviousness, that publishing the note to "more relays" should have predictably resulted in more replies, which, again, shouldn't be the case if Nostr is really censorship-resistant.

What happens is that most people who engaged with the note are following me, in the sense that they have instructed their clients to fetch my notes on their behalf and present them in the UI, and clients are failing to do that despite me making it clear in multiple ways that my notes are to be found on wss://pyramid.fiatjaf.com.

If we were talking not about me, but about some public figure that was being censored by the State and got banned (or shadowbanned) by the 3 biggest public relays, the sad reality would be that the person would immediately get his reach reduced to ~10% of what they had before. This is not at all unlike what happened to dozens of personalities that were banned from the corporate social media platforms and then moved to other platforms -- how many of their original followers switched to these other platforms? Probably some small percentage close to 10%. In that sense Nostr today is similar to what we had before.

Peter Todd is right that if the way Nostr works is that you just subscribe to a small set of relays and expect to get everything from them then it tends to get very centralized very fast, and this is the reality today.

Peter Todd is wrong that Nostr is inherently centralized or that it needs a protocol change to become what it has always purported to be. He is in fact wrong today, because what is written above is not valid for all clients of today, and if we drive in the right direction we can successfully make Peter Todd be more and more wrong as time passes, instead of the contrary.

---

See also:

• Censorship-resistant relay discovery in Nostr
• A vision for content discovery and relay usage for basic social-networking in Nostr

@ 3bf0c63f:aefa459d

Nostr: a quick introduction, attempt #2

Nostr doesn't subscribe to any ideals of "free speech" as these belong to the realm of politics and assume a big powerful government that enforces a common ruleupon everybody else.

Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process. In other words, Nostr is the public road that each market participant can use to build their own store or visit others and use their services.

(Of course a road is never truly public, in normal cases it's ran by the government, in this case it relies upon the previous existence of the internet with all its quirks and chaos plus a hand of government control, but none of that matters for this explanation).

More concretely speaking, Nostr is just a set of definitions of the formats of the data that can be passed between participants and their expected order, i.e. messages between clients (i.e. the program that runs on a user computer) and relays (i.e. the program that runs on a publicly accessible computer, a "server", generally with a domain-name associated) over a type of TCP connection (WebSocket) with cryptographic signatures. This is what is called a "protocol" in this context, and upon that simple base multiple kinds of sub-protocols can be added, like a protocol for "public-square style microblogging", "semi-closed group chat" or, I don't know, "recipe sharing and feedback".

@ 4f82bced:b8928630

Lusaka was a short stop as we headed towards Victoria Falls. Its infrastructure caught us off guard. Good roads, accessible amenities, and many malls. A stark contrast to Malawi, a neighboring country we had just visited. Entering one such mall in Lusaksa felt like we were back in Toronto. Driven by government, private, and foreign investment, Lusaka seemed to be miles ahead of other landlocked countries we had visited.

During our time in the city, we visited a restaurant that accepts bitcoin and hosts local bitcoin meet-ups. While interacting with the owner it was clear he viewed bitcoin as a competitive differentiator and an efficient easier form of payment acceptance. Since our meeting, he has increased his marketing efforts to raise awareness and inform his customers about bitcoin.

Victoria Falls (Mosi-oa-Tunya) is a major tourist attraction in Zambia, stretching nearly 1.7km! Due to recent droughts, the falls were no longer a blanket of water. Only certain sections had a steady flow, exposing the rock formations behind the water, an uncommon sight for visitors.

The waterfalls aside, we were invited to speak at the Bitcoin community meetup, Bitcoin Victoria Falls. The founder of this community is American, who decided to kickstart the project during a recent visit to the area. It was the first time we had encountered a community founded by a foreigner who didn't live in the region. It shows that anyone can bring forth change regardless of where they live! Can't forget his co-founder and running mate, Humprey, a local who has helped progress their mission!

Our presentation topic? Bitcoin for Businesses. We discussed the basics of bitcoin, how it works, how to earn it, and most importantly, how to onboard merchants. It's great interacting with the local community to understand their challenges. Fortunately, this community has decent bitcoin penetration. The lodge where the meetup was held accepts bitcoin, including a taxi service, a tour operator, and a stationary provider. During our stay, we onboarded the bar and its servers within the lodge premises. The owners appreciated the speed at which they could settle payments and easily accept money from foreigners who may not have cash.

Did you know, that the Zambezi River which runs below Victoria Falls is world renowned for its white water rafting? We had the chance to experience it ourselves and pay with bitcoin!

Botswana here we come.

Sources: Victoria Falls. Britannia. https://www.britannica.com/place/Victoria-Falls-waterfall-Zambia-Zimbabwe

@ 460c25e6:ef85065c

NIPs (Nostr Implementation Possibilities) are technical specifications that Nostr developers create to define how specific event types and tags are used. These can be written before or after the feature is implemented and often go through multiple revisions before becoming stable enough to matter. Once two or more clients fully implement the proposal, it is merged into the main repository. This process ensures that while new ideas are encouraged, they are also rigorously reviewed and tested.

There are generally two paths for NIPs: 1. New Ideas, when developers just have a hunch on a new solution and want to quickly write something up to gather feedback from the community. These are my favorite NIPs because they generally introduce a new way of thinking about a problem we are all having. And because they are not just a general solution, but a specific proposal, it allows us to see the entire picture in just a few paragraphs. Even though they are my favorite, they are quite "green" and usually spur 2-3 separate solutions in following PRs by different authors. 2. Existing implementations that need to explain what they are doing. These happen when a client is already running the code in production and simply wants to explain to the rest of the community how to generate and interpret the events the client is creating. These NIPs start much more stable than the former and allow for fewer changes, but because there is already an implementation available, it's a market-tested solution that might just need a few adjustments before others start implementing it.

Well-written specs ensure clarity, reduce ambiguity, and help developers implement the proposal consistently. The text should be VERY short, precise, prescriptive, and actionable by other devs. Start by introducing the new kind or tag in the first sentence and jump straight into a mockup of how the event looks like. The mockup should be self-explanatory and provide clues to what the remaining of the document will talk about. Some folks like to add long/verbose introductions, conclusions, and discussions of the reasons why the NIP is needed or why certain features are there. But those are largely unnecessary and are more appropriate to be placed in the body of the Pull Request descriptor.

Start your NIP with the following template:

``` NIP- ======