@ 2183e947:f497b975

Most darknet markets (DNMs) are designed poorly in the following ways:

1. Hosting

Most DNMs use a model whereby merchants fill out a form to create their listings, and the data they submit then gets hosted on the DNM's servers. In scenarios where a "legal" website would be forced to censor that content (e.g. a DMCA takedown order), DNMs, of course, do not obey. This can lead to authorities trying to find the DNM's servers to take enforcement actions against them. This design creates a single point of failure.

A better design is to outsource hosting to third parties. Let merchants host their listings on nostr relays, not on the DNM's server. The DNM should only be designed as an open source interface for exploring listings hosted elsewhere, that way takedown orders end up with the people who actually host the listings, i.e. with nostr relays, and not with the DNM itself. And if a nostr relay DOES go down due to enforcement action, it does not significantly affect the DNM -- they'll just stop querying for listings from that relay in their next software update, because that relay doesn't work anymore, and only query for listings from relays that still work.

2. Moderation

Most DNMs have employees who curate the listings on the DNM. For example, they approve/deny listings depending on whether they fit the content policies of the website. Some DNMs are only for drugs, others are only for firearms. The problem is, to approve a criminal listing is, in the eyes of law enforcement, an act of conspiracy. Consequently, they don't just go after the merchant who made the listing but the moderators who approved it, and since the moderators typically act under the direction of the DNM, this means the police go after the DNM itself.

A better design is to outsource moderation to third parties. Let anyone call themselves a moderator and create lists of approved goods and services. Merchants can pay the most popular third party moderators to add their products to their lists. The DNM itself just lets its users pick which moderators to use, such that the user's choice -- and not a choice by the DNM -- determines what goods and services the user sees in the interface.

That way, the police go after the moderators and merchants rather than the DNM itself, which is basically just a web browser: it doesn't host anything or approve of any content, it just shows what its users tell it to show. And if a popular moderator gets arrested, his list will still work for a while, but will gradually get more and more outdated, leading someone else to eventually become the new most popular moderator, and a natural transition can occur.

3. Escrow

Most DNMs offer an escrow solution whereby users do not pay merchants directly. Rather, during the Checkout process, they put their money in escrow, and request the DNM to release it to the merchant when the product arrives, otherwise they initiate a dispute. Most DNMs consider escrow necessary because DNM users and merchants do not trust one another; users don't want to pay for a product first and then discover that the merchant never ships it, and merchants don't want to ship a product first and then discover that the user never pays for it.

The problem is, running an escrow solution for criminals is almost certain to get you accused of conspiracy, money laundering, and unlicensed money transmission, so the police are likely to shut down any DNM that does this. A better design is to oursource escrow to third parties. Let anyone call themselves an escrow, and let moderators approve escrows just like they approve listings. A merchant or user who doesn't trust the escrows chosen by a given moderator can just pick a different moderator. That way, the police go after the third party escrows rather than the DNM itself, which never touches user funds.

4. Consequences

Designing a DNM along these principles has an interesting consequence: the DNM is no longer anything but an interface, a glorified web browser. It doesn't host any content, approve any listings, or touch any money. It doesn't even really need a server -- it can just be an HTML file that users open up on their computer or smart phone. For two reasons, such a program is hard to take down:

First, it is hard for the police to justify going after the DNM, since there are no charges to bring. Its maintainers aren't doing anything illegal, no more than Firefox does anything illegal by maintaining a web browser that some people use to browse illegal content. What the user displays in the app is up to them, not to the code maintainers. Second, if the police decided to go after the DNM anyway, they still couldn't take it down because it's just an HTML file -- the maintainers do not even need to run a server to host the file, because users can share it with one another, eliminating all single points of failure.

Another consequence of this design is this: most of the listings will probably be legal, because there is more demand for legal goods and services than illegal ones. Users who want to find illegal goods would pick moderators who only approve those listings, but everyone else would use "legal" moderators, and the app would not, at first glance, look much like a DNM, just a marketplace for legal goods and services. To find the illegal stuff that lurks among the abundant legal stuff, you'd probably have to filter for it via your selection of moderators, making it seem like the "default" mode is legal.

5. Conclusion

I think this DNM model is far better than the designs that prevail today. It is easier to maintain, harder to take down, and pushes the "hard parts" to the edges, so that the DNM is not significantly affected even if a major merchant, moderator, or escrow gets arrested. I hope it comes to fruition.

@ 21335073:a244b1ad

Please respect Virginia Giuffre’s memory by refraining from asking about the circumstances or theories surrounding her passing.

Since Virginia Giuffre’s death, I’ve reflected on what she would want me to say or do. This piece is my attempt to honor her legacy.

When I first spoke with Virginia, I was struck by her unshakable hope. I had grown cynical after years in the anti-human trafficking movement, worn down by a broken system and a government that often seemed complicit. But Virginia’s passion, creativity, and belief that survivors could be heard reignited something in me. She reminded me of my younger, more hopeful self. Instead of warning her about the challenges ahead, I let her dream big, unburdened by my own disillusionment. That conversation changed me for the better, and following her lead led to meaningful progress.

Virginia was one of the bravest people I’ve ever known. As a survivor of Epstein, Maxwell, and their co-conspirators, she risked everything to speak out, taking on some of the world’s most powerful figures.

She loved when I said, “Epstein isn’t the only Epstein.” This wasn’t just about one man—it was a call to hold all abusers accountable and to ensure survivors find hope and healing.

The Epstein case often gets reduced to sensational details about the elite, but that misses the bigger picture. Yes, we should be holding all of the co-conspirators accountable, we must listen to the survivors’ stories. Their experiences reveal how predators exploit vulnerabilities, offering lessons to prevent future victims.

You’re not powerless in this fight. Educate yourself about trafficking and abuse—online and offline—and take steps to protect those around you. Supporting survivors starts with small, meaningful actions. Free online resources can guide you in being a safe, supportive presence.

When high-profile accusations arise, resist snap judgments. Instead of dismissing survivors as “crazy,” pause to consider the trauma they may be navigating. Speaking out or coping with abuse is never easy. You don’t have to believe every claim, but you can refrain from attacking accusers online.

Society also fails at providing aftercare for survivors. The government, often part of the problem, won’t solve this. It’s up to us. Prevention is critical, but when abuse occurs, step up for your loved ones and community. Protect the vulnerable. it’s a challenging but a rewarding journey.

If you’re contributing to Nostr, you’re helping build a censorship resistant platform where survivors can share their stories freely, no matter how powerful their abusers are. Their voices can endure here, offering strength and hope to others. This gives me great hope for the future.

Virginia Giuffre’s courage was a gift to the world. It was an honor to know and serve her. She will be deeply missed. My hope is that her story inspires others to take on the powerful.

@ 52b4a076:e7fad8bd

I have been recently building NFDB, a new relay DB. This post is meant as a short overview.

Regular relays have challenges

Current relay software have significant challenges, which I have experienced when hosting Nostr.land: - Scalability is only supported by adding full replicas, which does not scale to large relays. - Most relays use slow databases and are not optimized for large scale usage. - Search is near-impossible to implement on standard relays. - Privacy features such as NIP-42 are lacking. - Regular DB maintenance tasks on normal relays require extended downtime. - Fault-tolerance is implemented, if any, using a load balancer, which is limited. - Personalization and advanced filtering is not possible. - Local caching is not supported.

NFDB: A scalable database for large relays

NFDB is a new database meant for medium-large scale relays, built on FoundationDB that provides: - Near-unlimited scalability - Extended fault tolerance - Instant loading - Better search - Better personalization - and more.

Search

NFDB has extended search capabilities including: - Semantic search: Search for meaning, not words. - Interest-based search: Highlight content you care about. - Multi-faceted queries: Easily filter by topic, author group, keywords, and more at the same time. - Wide support for event kinds, including users, articles, etc.

Personalization

NFDB allows significant personalization: - Customized algorithms: Be your own algorithm. - Spam filtering: Filter content to your WoT, and use advanced spam filters. - Topic mutes: Mute topics, not keywords. - Media filtering: With Nostr.build, you will be able to filter NSFW and other content - Low data mode: Block notes that use high amounts of cellular data. - and more

Other

NFDB has support for many other features such as: - NIP-42: Protect your privacy with private drafts and DMs - Microrelays: Easily deploy your own personal microrelay - Containers: Dedicated, fast storage for discoverability events such as relay lists

Calcite: A local microrelay database

Calcite is a lightweight, local version of NFDB that is meant for microrelays and caching, meant for thousands of personal microrelays.

Calcite HA is an additional layer that allows live migration and relay failover in under 30 seconds, providing higher availability compared to current relays with greater simplicity. Calcite HA is enabled in all Calcite deployments.

For zero-downtime, NFDB is recommended.

Noswhere SmartCache

Relays are fixed in one location, but users can be anywhere.

Noswhere SmartCache is a CDN for relays that dynamically caches data on edge servers closest to you, allowing: - Multiple regions around the world - Improved throughput and performance - Faster loading times

routerd

routerd is a custom load-balancer optimized for Nostr relays, integrated with SmartCache.

routerd is specifically integrated with NFDB and Calcite HA to provide fast failover and high performance.

Ending notes

NFDB is planned to be deployed to Nostr.land in the coming weeks.

A lot more is to come. 👀️️️️️️

@ 40b9c85f:5e61b451

Introduction

Data Vending Machines (DVMs) have emerged as a crucial component of the Nostr ecosystem, offering specialized computational services to clients across the network. As defined in NIP-90, DVMs operate on an apparently simple principle: "data in, data out." They provide a marketplace for data processing where users request specific jobs (like text translation, content recommendation, or AI text generation)

While DVMs have gained significant traction, the current specification faces challenges that hinder widespread adoption and consistent implementation. This article explores some ideas on how we can apply the reflection pattern, a well established approach in RPC systems, to address these challenges and improve the DVM ecosystem's clarity, consistency, and usability.

The Current State of DVMs: Challenges and Limitations

The NIP-90 specification provides a broad framework for DVMs, but this flexibility has led to several issues:

1. Inconsistent Implementation

As noted by hzrd149 in "DVMs were a mistake" every DVM implementation tends to expect inputs in slightly different formats, even while ostensibly following the same specification. For example, a translation request DVM might expect an event ID in one particular format, while an LLM service could expect a "prompt" input that's not even specified in NIP-90.

2. Fragmented Specifications

The DVM specification reserves a range of event kinds (5000-6000), each meant for different types of computational jobs. While creating sub-specifications for each job type is being explored as a possible solution for clarity, in a decentralized and permissionless landscape like Nostr, relying solely on specification enforcement won't be effective for creating a healthy ecosystem. A more comprehensible approach is needed that works with, rather than against, the open nature of the protocol.

3. Ambiguous API Interfaces

There's no standardized way for clients to discover what parameters a specific DVM accepts, which are required versus optional, or what output format to expect. This creates uncertainty and forces developers to rely on documentation outside the protocol itself, if such documentation exists at all.

The Reflection Pattern: A Solution from RPC Systems

The reflection pattern in RPC systems offers a compelling solution to many of these challenges. At its core, reflection enables servers to provide metadata about their available services, methods, and data types at runtime, allowing clients to dynamically discover and interact with the server's API.

In established RPC frameworks like gRPC, reflection serves as a self-describing mechanism where services expose their interface definitions and requirements. In MCP reflection is used to expose the capabilities of the server, such as tools, resources, and prompts. Clients can learn about available capabilities without prior knowledge, and systems can adapt to changes without requiring rebuilds or redeployments. This standardized introspection creates a unified way to query service metadata, making tools like grpcurl possible without requiring precompiled stubs.

How Reflection Could Transform the DVM Specification

By incorporating reflection principles into the DVM specification, we could create a more coherent and predictable ecosystem. DVMs already implement some sort of reflection through the use of 'nip90params', which allow clients to discover some parameters, constraints, and features of the DVMs, such as whether they accept encryption, nutzaps, etc. However, this approach could be expanded to provide more comprehensive self-description capabilities.

1. Defined Lifecycle Phases

Similar to the Model Context Protocol (MCP), DVMs could benefit from a clear lifecycle consisting of an initialization phase and an operation phase. During initialization, the client and DVM would negotiate capabilities and exchange metadata, with the DVM providing a JSON schema containing its input requirements. nip-89 (or other) announcements can be used to bootstrap the discovery and negotiation process by providing the input schema directly. Then, during the operation phase, the client would interact with the DVM according to the negotiated schema and parameters.

2. Schema-Based Interactions

Rather than relying on rigid specifications for each job type, DVMs could self-advertise their schemas. This would allow clients to understand which parameters are required versus optional, what type validation should occur for inputs, what output formats to expect, and what payment flows are supported. By internalizing the input schema of the DVMs they wish to consume, clients gain clarity on how to interact effectively.

3. Capability Negotiation

Capability negotiation would enable DVMs to advertise their supported features, such as encryption methods, payment options, or specialized functionalities. This would allow clients to adjust their interaction approach based on the specific capabilities of each DVM they encounter.

Implementation Approach

While building DVMCP, I realized that the RPC reflection pattern used there could be beneficial for constructing DVMs in general. Since DVMs already follow an RPC style for their operation, and reflection is a natural extension of this approach, it could significantly enhance and clarify the DVM specification.

A reflection enhanced DVM protocol could work as follows: 1. Discovery: Clients discover DVMs through existing NIP-89 application handlers, input schemas could also be advertised in nip-89 announcements, making the second step unnecessary. 2. Schema Request: Clients request the DVM's input schema for the specific job type they're interested in 3. Validation: Clients validate their request against the provided schema before submission 4. Operation: The job proceeds through the standard NIP-90 flow, but with clearer expectations on both sides

Parallels with Other Protocols

This approach has proven successful in other contexts. The Model Context Protocol (MCP) implements a similar lifecycle with capability negotiation during initialization, allowing any client to communicate with any server as long as they adhere to the base protocol. MCP and DVM protocols share fundamental similarities, both aim to expose and consume computational resources through a JSON-RPC-like interface, albeit with specific differences.

gRPC's reflection service similarly allows clients to discover service definitions at runtime, enabling generic tools to work with any gRPC service without prior knowledge. In the REST API world, OpenAPI/Swagger specifications document interfaces in a way that makes them discoverable and testable.

DVMs would benefit from adopting these patterns while maintaining the decentralized, permissionless nature of Nostr.

Conclusion

I am not attempting to rewrite the DVM specification; rather, explore some ideas that could help the ecosystem improve incrementally, reducing fragmentation and making the ecosystem more comprehensible. By allowing DVMs to self describe their interfaces, we could maintain the flexibility that makes Nostr powerful while providing the structure needed for interoperability.

For developers building DVM clients or libraries, this approach would simplify consumption by providing clear expectations about inputs and outputs. For DVM operators, it would establish a standard way to communicate their service's requirements without relying on external documentation.

I am currently developing DVMCP following these patterns. Of course, DVMs and MCP servers have different details; MCP includes capabilities such as tools, resources, and prompts on the server side, as well as 'roots' and 'sampling' on the client side, creating a bidirectional way to consume capabilities. In contrast, DVMs typically function similarly to MCP tools, where you call a DVM with an input and receive an output, with each job type representing a different categorization of the work performed.

Without further ado, I hope this article has provided some insight into the potential benefits of applying the reflection pattern to the DVM specification.

@ b2caa9b3:9eab0fb5

Yesterday, I faced one of the most heartbreaking and frustrating experiences of my life. Between 10:00 AM and 2:00 PM, I was held at the Taveta border, denied entry into Kenya—despite having all the necessary documents, including a valid visitor’s permit and an official invitation letter.

The Kenyan Immigration officers refused to speak with me. When I asked for clarification, I was told flatly that I would never be allowed to enter Kenya unless I obtain a work permit. No other reason was given. My attempts to explain that I simply wanted to see my child were ignored. No empathy. No flexibility. No conversation. Just rejection.

While I stood there for hours, held by officials with no explanation beyond a bureaucratic wall, I recorded the experience. I now have several hours of footage documenting what happened—a silent testimony to how a system can dehumanize and block basic rights.

And the situation doesn’t end at the border.

My child, born in Kenya, is also being denied the right to see me. Germany refuses to grant her citizenship, which means she cannot visit me either. The German embassy in Nairobi refuses to assist, stating they won’t get involved. Their silence is loud.

This is not just about paperwork. This is about a child growing up without her father. It’s about a system that chooses walls over bridges, and bureaucracy over humanity. Kenya, by refusing me entry, is keeping a father away from his child. Germany, by refusing to act under §13 StGB, is complicit in that injustice.

In the coming days, I’ll share more about my past travels and how this situation unfolded. I’ll also be releasing videos and updates on TikTok—because this story needs to be heard. Not just for me, but for every parent and child caught between borders and bureaucracies.

Stay tuned—and thank you for standing with me.