@ 0e67f053:cb1d4b93

By Carl Tuckerson, Who Weeps During City Council Meetings

Democracy is not a system.

It is a living, breathing organism, pulsating with the ancestral heartbeat of every barefoot revolutionary who ever composted oppression into community gardens of change.

It is consent manifested, a tapestry woven by the trembling hands of the marginalized and the mildly inconvenienced alike. It is radical accountability on a biodegradable ballot.

Democracy is the collective inhale of a million voices saying, “Yes, I matter,” and the collective exhale of power releasing its grip—not because it was forced to, but because it finally understood its own trauma.

It is fluid, non-binary, and consensually participatory. A polyamorous relationship between people, policy, and purpose. No labels. Just vibes.

It is the sacred act of showing up—in person, in spirit, in ethically sourced linen—because you believe that your voice, no matter how tremulously intersectional, is a note in the symphony of collective liberation.

Democracy is not red or blue. It’s not even purple. It’s the entire spectrum of human expression, from burnt sienna to sunset glitter sparkle.

It is brunch and ballots. It is protest and poetry. It is tweeting while crying while registering your roommate to vote.

It is government of the people, by the people, and for the people, but especially for the people who’ve been gaslit by history.

And when democracy falters, we don’t abolish it—we give it a weighted blanket, whisper affirmations into its ear, and tell it to take the day off, because healing is not linear.

So what is democracy?

It’s not a noun.It’s not even a verb.It’s a sacred energy exchange—and if you listen closely, you can hear it humming in the compost bin behind your community center.

Namaste. Vote. And remember: ballots are spells cast in ink. Use yours wisely.

— Carl, “Decolonize the Vote” Tuckerson

originally posted at https://stacker.news/items/956879

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

@ e4950c93:1b99eccd

Heureu-x-se d’avoir trouvé une information utile sur ce site ?

Soutenez le projet en faisant un don pour le faire vivre et remercier les contribut-eur-rice-s.

---

En bitcoin

• Sur la blockchain : bc1qkm8me8l9563wvsl9sklzt4hdcuny3tlejznj7d

• Réseau lightning : ⚡️origin-nature@coinos.io Vous pouvez aussi nous soutenir de manière récurrente 👉 Créer un paiement Lightning récurrent

---

En euros, dollars, ou toute autre monnaie prise en charge

• Par virement, IBAN : FR76 2823 3000 0144 3759 8717 669

• Vous pouvez aussi nous soutenir de manière récurrente 👉 Faire une promesse sur LiberaPay

---

Contactez-nous si vous souhaitez faire un don avec toute autre cryptomonnaie.

---

💡 Un modèle de partage de la valeur

La moitié des dons est redistribuée aux contribut-eur-rice-s qui créent la valeur du site, pour expérimenter un modèle de partage de revenus sur Internet — un modèle qui respecte vos données et ne cherche pas à capter votre attention. L’autre moitié permet de couvrir les frais de fonctionnement du site.

---

Cet article est publié sur origine-nature.com 🌐 See this article in English

@ 1f79058c:eb86e1cb

I'm currently using this bash script to publish long-form content from local Markdown files to Nostr relays.

It requires all of yq, jq, and nak to be installed.

Usage

Create a signed Nostr event and print it to the console:

markdown_to_nostr.sh article-filename.md

Create a Nostr event and publish it to one or more relays:

markdown_to_nostr.sh article-filename.md ws://localhost:7777 wss://nostr.kosmos.org

Markdown format

You can specify your metadata as YAML in a Front Matter header. Here's an example file:

```md

title: "Good Morning" summary: "It's a beautiful day" image: https://example.com/i/beautiful-day.jpg date: 2025-04-24T15:00:00Z tags: gm, poetry published: false

---

In the blue sky just a few specks of gray
In the evening of a beautiful day
Though last night it rained and more rain on the way
And that more rain is needed 'twould be fair to say.

— Francis Duggan ```

The metadata keys are mostly self-explanatory. Note:

• All keys except for title are optional
• date, if present, will be set as the published_at date.
• If published is set to true, it will publish a kind 30023 event, otherwise a kind 30024 (draft)
• The d tag (widely used as URL slug for the article) will be the filename without the .md extension