timp
Tim

Poastor, internet explorer, yolo coder #PardonSamourai

Public Key

npub1yn8hfcgjtqe7jaftfpp79zraahwldyggjmnws23daa5vs5napq2qex6pzj

NIP-05 Address

Profile Code

nprofile1qqszfnm5uyf9svlfw545sslz3p77mh0kjyyfdehg9gk776xg2f7ss9qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdq3nsu

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1yn8hfcgjtqe7jaftfpp79zraahwldyggjmnws23daa5vs5napq2qex6pzj

Show more details

Last Notes

2026-01-30 23:31:32 UTC

https://blossom.primal.net/696265de5a5ce9e0ab8417146ad709326fb37e2626e37082c8c16960217f1411.png
My dad worked on computers before I was born, back when machines did not pretend to be friendly. He wrote the code, built the machines, wired them together, and listened for sounds that meant trouble. Fans had a pitch and drives had a rhythm. When something went wrong, you often heard it before you saw it.
In the eighties he became a system administrator, before that phrase turned into a job title. Back then it meant you owned the whole system. There was no one else to hand it off to. If something failed, it failed right there, in the same room. It left you with little choice other than rolling a cigarette and fixing it.
Back then, systems did not reach very far. That was not a limitation. It was the reason they worked. A disk could fail without pulling anything else down with it. A program could crash and stay crashed. You always knew where the edge was because it was right there in the room with you.
Trust lived inside those edges. If you gave something access, you knew what it could touch. If you handed someone a key, you knew which door it opened. When a mistake happened, the damage stopped where the system stopped. Abuse existed, but it demanded effort. You had to show up. You had to spend time and hardware and attention.
That way of working did not vanish because it was flawed. It vanished because it could not survive success.
More people started using computers. Machines began to speak across rooms, then across cities, then across continents. Software left the building and never came back. At some point nobody could point at the whole system anymore. Responsibility stretched thin and then dissolved. Nothing about that was reckless. It was scale doing what scale does.
The failures changed shape.
Now when an application disappears, your data goes with it. When an account closes, years of context vanish in the same motion. We pretend this is normal. We call it convenience. We accept it because pushing back feels futile. The old alternatives have faded far enough that we barely remember them.
These systems assume they will keep working. They assume the platform will still exist tomorrow. They assume nothing important will fail at the wrong time. When those assumptions break, everything breaks together.
That is also why abuse spreads so easily. Identity is cheap because it has no weight. Authority slips in unnoticed because it is never clearly granted. Reach appears by default. You do not earn it. You inherit it by showing up.
Moderation shows up after the damage is done. There is nowhere else for it to go. By that point the system has already chosen what spreads and what survives. At scale it turns into endless cleanup, not control.
We tried to fix it with cryptography. We locked the wires. We stamped messages. We built systems that promised safety if you followed the rules closely enough. What people got were setups that offered no forgiveness. One wrong move and the door slammed shut.
Most people stepped away because the price of a small error was total loss. Years could vanish without warning. That is not security. That is fragility. Even Phil Zimmermann, who invented PGP, has said he does not use it himself, because he couldn’t be bothered spending time learning how to set it up correctly.
The failure was not the math. It was where we placed it.
There is another way to approach this. It starts by letting go of the idea that software should be permanent. It accepts that things will fail. It treats that as normal instead of catastrophic.
This is where 2WAY comes in. It starts from a simple idea:
On 2WAY, your data does not belong to the application that happens to display it. It lives locally, shaped in a way other software can understand. An app can leave without dragging your history behind it. Another can step in and continue.
This changes how access works. Nothing acts just because it exists. Permission has to be given. Not once, not vaguely, and not forever. When something is allowed to do something, that allowance has a shape. When it ends, it ends cleanly.
You do not see the cryptography most of the time. It does its work quietly. What you see are moments where a decision is required. A choice to allow something. A choice to stop it later. Recovery is expected and mistakes do not poison the whole system. As a result, failure stops spreading.
If a service disappears, your data stays put. If software misbehaves, it cannot wander into places it was never invited to. If trust breaks, it breaks along a line you can point at.
Abuse becomes harder because it has to push against structure. New identities arrive without weight. They do not reach far unless other identities lay the groundwork for them. That takes time. It takes effort. It cannot be faked cheaply.
Misinformation looks different too. The problem was never that people lie. The problem is that content floats free of its past. In this kind of system, where something came from is not a mystery. What happened to it along the way leaves marks. You are not forced to believe any of it. You can see enough to decide.
This matters more as machines begin to act on our behalf. An assistant that can do everything is dangerous. One that can only act within clear limits is dull in the right way. When it fails, it stops instead of spreading the damage.
Something else happens along the way. Patterns that rely on quiet overreach stop working. An application cannot slowly take more than it was given. It cannot blur the boundary and hope no one notices. That kind of behavior becomes visible because it has to ask.
Power shifts.
Platforms lose their grip because they no longer own the ground beneath you. Software competes again on usefulness. Lock-in fades because there is nothing left to hold.
None of this fixes people. Conflict remains. Deception remains. But the systems stop amplifying the worst behavior just because it is cheap.
We are moving into a world filled with generated voices, synthetic images, and automated decisions. Implicit trust will not survive. Assumptions turn into attack surfaces. Silence becomes risk.
The only thing that scales safely is clarity. Clear authority. Explicit boundaries. Systems that know what they are allowed to do and nothing beyond that.
Software should be allowed to die. Your data should stay where it is. Your identity should not thin out or vanish because a service closed its doors.
That is what 2WAY is trying to make boring again.
It is not a product yet. It is a shape. The protocol and backend are written down. The boundaries exist. The hard parts are named. What exists today is the structure, not the machine that runs it.
I am still finalizing that structure. I am looking for weak joints. I am checking where assumptions leak. I want the limits to hold before anything is turned on.
When that work settles, I will start another build iteration.
The protocol and backend specifications are practically ready, MIT licensed, and live here:
https://github.com/livegnik/2way-poc-design
If this way of thinking aligns with you, the work is open. There is room to work on it together.

2026-01-17 17:53:47 UTC

- reply

Thanks for your time and interest. If you have any questions, I'd be happy to answer them. Any and all feedback is very welcome.

2026-01-17 14:40:41 UTC

- reply

GM!
On it.

2026-01-17 14:01:08 UTC

- reply

That sounds sensible and underappreciated indeed.
2WAY is concerned with what happens once data reaches the node and multiple parties can affect the same state. Shared state needs rules that are explicit and applied the same way everywhere, otherwise different nodes will reach different conclusions over time. In 2WAY those rules are enforced by the system itself rather than reconstructed by applications. It sounds like Reticulum can move data very well, but does not aim to define or enforce shared history, which is the problem 2WAY is built to solve.

2026-01-17 13:33:36 UTC

- reply

If you are familiar with Zen and want a clearer sense of how 2WAY differs, it helps to read sections “7. Security model,” “8. Incentives,” and “9. Privacy” first.
They explain the underlying assumptions and tradeoffs before the architecture details, which makes the rest of the design easier to place.

2026-01-17 13:26:26 UTC

- reply

Thanks for pointing it out. This is the first time I'm reading about it.
It seems Zen is about moving data across unreliable networks and making sure messages can get through without infrastructure, but seems to avoid defining what those messages mean, who is allowed to send them, how they should be ordered, or how shared history should work.
2WAY does all that too, by defining how state is validated, authorized, ordered, and shared so different parties can converge on the same result without relying on transport behavior or application-level convention.

2026-01-16 18:44:49 UTC

- reply

tl;dr:
https://blossom.primal.net/b711200667fee903a0e324655a7f6dac25de1957cac9d152f71776c44dd556d7.png

2026-01-16 18:44:22 UTC

Nostr's NIP-01 explains what an event looks like and how the cryptography works. It defines the data model.
It does not describe a clear validation model, and I could not find one elsewhere. So I tried to write one.
Feedback is very welcome.
https://github.com/nostr-protocol/nips/issues/2188

2026-01-16 13:08:59 UTC

GM
https://www.youtube.com/watch?v=RwP1liHjpI8

2026-01-15 16:57:55 UTC

- reply

Only 2 legit OPSEC assumptions:
1) All your stuff is compromised;
2) Apart from point 1, never assume anything.

2026-01-15 02:02:02 UTC

- reply

tl;dr:
https://image.nostr.build/9a3fed18f49f6f350f0d0add111561135562ce11b3b022fcd2b6825134ec9e0b.jpg

2026-01-15 00:56:49 UTC

2026-01-14 01:43:52 UTC

- reply

To you? Idk. Cheers.

2026-01-14 01:42:51 UTC

- reply

Working on my NIPs. Next one's on you. 🍻

2026-01-14 00:42:04 UTC

- reply

The NIP idea:
Define a mandatory, ordered validation pipeline for all NIP-01 events, applied identically by clients and relays. The pipeline must specify exact stages, required checks, and hard failure outcomes. At minimum: JSON parse, type checks for required fields, tag structure checks, canonical serialization, id recomputation, signature verification, and basic invariants such as non-null fields, correct types, and bounded sizes when the relay advertises them. The NIP must define when an event becomes "valid", and it must require that once an event is considered valid, it is immutable and treated as a stable operation input. The NIP must also define how implementations should report failures in a structured way, without changing the event format.
This NIP started after reading discussions around network behavior and trying to understand why certain edge cases keep showing up across different Nostr apps, even when everyone is following NIP-01. The core issue seems to be that while NIP-01 defines the event format and cryptographic rules, it leaves a lot of room for interpretation in how events are validated, and in what order those checks are applied. The strict validation pipeline here is intended to run on clients, relays, or both, so they can make the same decisions about what is valid, safe to store, and safe to render.
In practice, different clients and relays make slightly different assumptions about when an event is valid, when it is safe to store, and when it is safe to render. Those small differences tend to leak upward into app logic, where they show up as duplicates, replay handling, inconsistent threading, or special-case code paths that are hard to reason about and easy to get wrong.
That discussion, especially callebtc's work on "Gossip mesh topology + source-based routing" (https://github.com/permissionlesstech/bitchat-android/pull/445), clarified the boundary between problems that belong to propagation and problems that belong to validation. A lot of effort is rightly going into making event delivery more robust under reordering, reconnection, and partial views of the network. At the same time, validation itself remains loosely defined and inconsistently enforced, which means application code often ends up compensating for malformed or ambiguously valid events after the fact.
This NIP is not meant to solve ordering, convergence, or propagation issues. Those are network-level problems, and they need network-level solutions. What this NIP tries to do is narrower: reduce the number of bad or ambiguous inputs that make those problems harder to handle downstream. By making validation stricter and uniform, fewer edge cases reach application logic, and fixes at the networking layer do not have to defensively account for inconsistent event shapes or partial validation.
This NIP does not introduce new event fields, new message types, or new relay behavior. Instead, it proposes a single, explicit validation pipeline for NIP-01 events, with clear stages and a fail-closed approach. The idea is that every event, whether inbound from the network or created locally, passes through the same sequence of checks before anything else happens.
The goal is not to make Nostr more complex, but to reduce accidental complexity. By tightening and unifying validation early, clients and relays can rely on a shared definition of what a "valid event" is, and keep the rest of their code simpler and more predictable, regardless of how events propagate through the network.
What this NIP solves in general:
Nostr has a recurring class of bugs where "the protocol is simple" but implementations disagree on what "valid" means in practice. Some clients accept malformed tags and compensate later. Some relays enforce hidden constraints without describing them. Some code paths verify signatures early, others late. That inconsistency forces every app feature, threading, indexing, rendering, notifications, to become defensive code. This NIP stops that leak. When validation is strict and ordered, the ecosystem converges on one definition of "valid input", which reduces crashes, reduces duplicate handling inconsistencies, reduces weird replay behavior, and makes every downstream algorithm simpler because it can assume inputs are well-formed and verified.
Practical example of problems:
A client receives an event where `tags` is present but contains an element that is not an array of strings, for example a nested object or a null. One client ignores it and continues. Another client tries to parse an `e` or `p` tag and fails a cast, breaking thread reconstruction. A relay might accept it and store it, then other clients repeatedly trip on it forever. Or the opposite: one relay rejects it but another accepts it, so users see inconsistent timelines depending on relay choice. With this NIP, all implementations reject it at the same stage with the same meaning. The event never becomes storable or renderable, and the bug does not propagate.
What other NIPs this NIP relies on:
* NIP-01 (event format, serialization and signature rules).
Note: I'm relatively new to Nostr and very open to feedback on this. The NIP is meant as a starting point for discussion, not a final answer. I'm especially interested in hearing where it overlaps with existing work, where it might be too strict, or where it does not fit the direction Nostr is heading or other NIPs or discussions I may have missed or misinterpreted.

2026-01-14 00:05:21 UTC

# NIP Proposal: Strict Event Validation
`draft` `optional` `client` `relay`
This NIP defines a strict, uniform validation pipeline for NIP-01 events, so clients and relays can make the same decision about what is valid, what is safe to store, and what is safe to render. It does not change the NIP-01 event format or message flow.
## Motivation
NIP-01 defines the event format, how `id` is derived, and how relays acknowledge acceptance or rejection.
In practice, different implementations apply different checks, in different orders, and sometimes only partially. This causes common issues:
* Clients generate events that some relays reject, because validation differs.
* Clients accept and render malformed events that should be rejected, causing crashes, broken threads, and security risks.
* Relays accept malformed tags or inconsistent types, which later break indexing, filtering, and downstream clients.
* Libraries implement "whatever worked with this relay" instead of "what the protocol says".
The goal of this NIP is to standardize a minimal, strict pipeline that is:
* deterministic
* cheap to run
* compatible with NIP-01 semantics
* implementable on the client first, without requiring changes from relays
* usable by relays as a predictable acceptance layer
## Status and scope
This NIP is optional. It specifies validation behavior that may be implemented by clients, relays, or both.
This NIP does not:
* introduce new event fields
* introduce new message types
* define new event kinds or tags
* define relay policy or moderation rules beyond validation
* require changes to signature algorithms or encodings
## Conventions and terminology
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.
* **Raw event**: a JSON object received from the network or constructed locally, not yet validated.
* **Validated event**: an event that passed all checks in this NIP, and is safe to store, index, and render.
* **Strict validation**: the full pipeline defined here.
* **Validation context**: local configuration and relay limits, such as maximum sizes or timestamp windows.
## Background, NIP-01 invariants
NIP-01 defines the on-wire event fields, the `id` derivation serialization, and signature expectations.
Relays respond to `["EVENT", <event>]` with an `["OK", <event_id>, <true|false>, <message>]`, where `<message>` uses a machine-readable prefix followed by `:` and a human-readable message when rejecting, and may be empty when accepting.
## Specification
### 1. Validation pipeline ordering
Implementations MUST validate events in the following order, and MUST stop at the first failure.
1. Parse and basic JSON type check
2. Required fields and basic types
3. Canonical constraints (hex lengths, ranges, integer checks)
4. `id` recomputation and equality check
5. Signature verification
6. Tag structure and standard tag grammar
7. Contextual policy limits (optional, but with a standard mechanism)
8. Apply, store, index, render
Rationale: the pipeline enforces a single "gate" that all feature code depends on, so rendering, indexing, threading, and filtering never touch untrusted structures.
### 2. Parse and basic shape
A raw event MUST be a JSON object.
If parsing fails, or the value is not a JSON object, the event is invalid.
### 3. Required fields and basic types
A raw event MUST contain the following fields, matching the NIP-01 event format.
* `id`, type string
* `pubkey`, type string
* `created_at`, type number
* `kind`, type number
* `tags`, type array
* `content`, type string
* `sig`, type string
If any required field is missing, or any type does not match, the event is invalid.
### 4. Canonical constraints
To reduce differences between implementations and unsafe edge cases, strict validation applies the following canonical constraints.
#### 4.1 Hex fields
The following fields MUST be lowercase hex strings of fixed length:
* `id` MUST be 64 hex characters (32 bytes), lowercase
* `pubkey` MUST be 64 hex characters (32 bytes), lowercase
* `sig` MUST be 128 hex characters (64 bytes), lowercase
These constraints align with how NIP-01 describes these fields on the wire.
If any field fails these constraints, the event is invalid.
#### 4.2 Numeric fields
* `created_at` MUST be an integer representing unix timestamp seconds. NIP-01 defines it as unix timestamp in seconds, and uses it as a number in the serialization.
* `kind` MUST be an integer in the range 0 to 65535 inclusive, as per NIP-01.
If `created_at` or `kind` is not an integer, or if `kind` is out of range, the event is invalid.
Note: this NIP chooses strict integer enforcement to avoid cross-language float and integer conversion differences. NIP-01 serialization uses numbers, but the semantics described for `created_at` and `kind` are integer-based. Very old events (roughly 2021–2022) occasionally used floating-point `created_at` values; strict implementations may reject those, or make this check configurable if backward compatibility is required.
Note: the `kind` range here is the NIP-01 baseline. Some later NIPs use higher kind numbers in practice; strict implementations may choose to accept them or make the allowed range configurable.
### 5. Canonical `id` recomputation
Strict validation MUST recompute `id` exactly as described in NIP-01 and compare it for equality with the provided `id`.
#### 5.1 Serialization input structure
The serialization input MUST be the JSON array:
```
[
0,
<pubkey, as a lowercase hex string>,
<created_at, as a number>,
<kind, as a number>,
<tags, as an array of arrays of non-null strings>,
<content, as a string>
]
```
This is NIP-01's specified structure for deriving `event.id`.
#### 5.2 Tag value constraint for hashing
Because the serialization requires `<tags, as an array of arrays of non-null strings>`, strict validation MUST ensure, before hashing, that:
* `tags` is an array
* every element of `tags` is an array
* every element of each tag array is a string
* no element is null
If these constraints fail, the event is invalid.
#### 5.3 JSON serialization rules
Strict validation MUST follow NIP-01 rules to prevent implementation differences:
* UTF-8 encoding
* no whitespace, line breaks, or unnecessary formatting
* the required escape rules for the `content` field as defined in NIP-01
#### 5.4 Hash check
Compute:
* `payload = utf8(json_serialize(serialization_array))`
* `hash = sha256(payload)`
* `expected_id = lowercase_hex(hash)`
The event is valid only if `expected_id == event.id`.
### 6. Signature verification
After `id` matches, strict validation MUST verify the signature:
* Verify that `sig` is a valid Schnorr signature over the `id`, using `pubkey`, per NIP-01's stated signature scheme.
If signature verification fails, the event is invalid.
### 7. Tag grammar, general rules
After cryptographic validity, strict validation enforces uniform tag structure rules.
#### 7.1 Basic tag rules
* Each tag MUST be an array of one or more strings.
* The first element `tag[0]` is the tag name, and MUST be a non-empty string.
* All elements of a tag MUST be strings, and MUST NOT be null (this is already required for hashing).
If any of these fail, the event is invalid.
#### 7.2 Standard tags
NIP-01 defines standard tags `e`, `p`, and `a` and their conventional structure.
Strict validation enforces the following when these tags appear.
##### `e` tag
If `tag[0] == "e"`:
* `tag[1]` MUST exist and MUST be a 64-character lowercase hex event id
* `tag[2]` MAY exist and is a recommended relay URL string
* `tag[3]` MAY exist and MUST be a 64-character lowercase hex pubkey if present
##### `p` tag
If `tag[0] == "p"`:
* `tag[1]` MUST exist and MUST be a 64-character lowercase hex pubkey
* `tag[2]` MAY exist and is a recommended relay URL string
##### `a` tag
If `tag[0] == "a"`:
* `tag[1]` MUST exist and MUST follow the NIP-01 address format rules for addressable or replaceable events, including the required trailing colon for normal replaceable events as specified.
* `tag[2]` MAY exist and is a recommended relay URL string
If a standard tag fails its grammar, the event is invalid.
Note: This NIP does not attempt to validate the meaning of non-standard tags, only their structural safety.
Non-normative note: the exact `a` tag address format is specified in NIP-33 and related NIPs (for example, NIP-16 and NIP-32). Implementations SHOULD refer to those documents for details.
Non-normative note: other NIPs define structured tags (for example, delegation in NIP-26 or external identities in NIP-39). Implementations MAY add tag-specific validation for those tags. Strict validation here only mandates the `e`/`p`/`a` grammar plus safe structure for all tags.
### 8. Contextual policy limits
Strict validation defines a uniform way to apply local policy limits, without standardizing a single global policy.
Implementations MAY apply limits such as:
* maximum message size in bytes of the WebSocket JSON frame (UTF-8)
* maximum `content` length in Unicode characters (not bytes)
* maximum number of tag arrays
* acceptable `created_at` skew relative to local clock
* minimum proof of work difficulty if required by a relay
NIP-11 defines a standard way for relays to communicate limits such as `max_message_length` (bytes of the WebSocket JSON frame), `max_content_length` (Unicode character count, not bytes), `max_event_tags` (count of tag arrays), `min_pow_difficulty` (as defined in NIP-13), and `created_at_lower_limit`/`created_at_upper_limit` (relay policy limits). Clients implementing this NIP SHOULD apply relay-provided limits consistently when publishing to that relay.
Timestamp sanity windows are policy limits, not part of cryptographic validity. This avoids breaking NIP-59 use cases where timestamps may be manipulated and relays may apply their own limits.
If a contextual limit is violated, the event SHOULD be rejected with a reason that indicates policy, not cryptographic invalidity.
### 9. Applying validated events
After an event passes strict validation, implementations SHOULD treat it as immutable:
* store it keyed by `id`
* if the same `id` is seen again, treat as duplicate and ignore
* build indices and views from the stored canonical structure, not from raw inbound JSON
Relays already commonly communicate duplicate handling using the `OK` response message format, and NIP-01 gives examples such as `duplicate: already have this event`.
## Relay behavior
### Accepting `EVENT`
Relays implementing this NIP SHOULD perform strict validation for every inbound `EVENT`.
* If accepted, respond with `["OK", <event_id>, true, <message>]` where `<message>` MAY be empty.
* If rejected, respond with `["OK", <event_id>, false, <message>]` where `<message>` MUST begin with a machine-readable prefix, followed by `:` and a human-readable message.
Relays that require authentication via NIP-42 MAY use `AUTH` challenges before accepting events. In those cases, `auth-required:` and `restricted:` prefixes may appear in `OK` or `CLOSED` messages to indicate policy or authorization failure, not event-format or cryptographic invalidity. Clients MUST NOT treat these as `invalid:` failures.
### Recommended error prefixes for strict validation
This NIP recommends using the existing NIP-01 error pattern and the `invalid:` prefix family only for NIP-01 structural or cryptographic violations. All other rejections, including NIP-42 authentication or authorization failures, MUST use non-`invalid` policy-style prefixes.
Use:
* `invalid: parse` for non-JSON or non-object
* `invalid: missing-field <field>`
* `invalid: type <field>`
* `invalid: hex <field>`
* `invalid: range kind`
* `invalid: id-mismatch`
* `invalid: sig`
* `invalid: tags-structure`
* `invalid: tag-e`
* `invalid: tag-p`
* `invalid: tag-a`
Example:
* `["OK", "<id>", false, "invalid: id-mismatch"]`
* `["OK", "<id>", false, "invalid: tag-e"]`
Policy-related failures SHOULD use non-`invalid` prefixes, for example:
* `rate-limited: ...`
* `restricted: ...`
* `auth-required: ...`
* `pow: ...`
These prefixes and the overall format are aligned with NIP-01 examples.
## Client behavior
Clients implementing this NIP SHOULD:
1. Validate before signing and publishing
2. Validate after receiving from relays, before storing or rendering
3. Ensure feature code never consumes raw events
Clients SHOULD apply relay limits when publishing, based on NIP-11 relay information, to reduce rejected publishes and inconsistent behavior across relays.
## Compatibility
* This NIP is compatible with the NIP-01 on-wire event format and message flow.
* This NIP may cause some older or malformed events to be rejected by strict implementations, especially events with non-integer `created_at` or malformed tags. This is intentional for strict mode.
Clients that want maximum backwards compatibility MAY support a "base mode" that only enforces NIP-01 minimums, and a "strict mode" that enforces this NIP.
## Security considerations
Strict validation reduces risk by:
* preventing malformed tag structures from reaching indexing and rendering
* preventing signature bypass through type confusion
* ensuring `id` and signature checks happen before any feature logic
* preventing divergent `id` calculations across implementations by forcing uniform serialization rules
This NIP does not solve spam or abuse by itself, but it provides a safer base for rate limiting and policy enforcement.
## Reference algorithm (pseudocode)
```
function validate_strict(event, context):
# 1. parse and shape
assert is_object(event)
# 2. required fields and basic types
require_fields(event, ["id","pubkey","created_at","kind","tags","content","sig"])
assert is_string(event.id)
assert is_string(event.pubkey)
assert is_number(event.created_at)
assert is_number(event.kind)
assert is_array(event.tags)
assert is_string(event.content)
assert is_string(event.sig)
# 3. canonical constraints
assert is_lower_hex(event.id, 64)
assert is_lower_hex(event.pubkey, 64)
assert is_lower_hex(event.sig, 128)
assert is_integer(event.created_at)
assert is_integer(event.kind)
assert 0 <= event.kind <= 65535
# optional: allow legacy float created_at in compatibility mode
# 4. tags hashing constraint
for tag in event.tags:
assert is_array(tag)
assert len(tag) >= 1
for x in tag:
assert is_string(x) and x is not null
assert tag[0] != ""
# 5. recompute id per NIP-01
ser = [0, event.pubkey, event.created_at, event.kind, event.tags, event.content]
payload = utf8(json_serialize_no_whitespace_with_nip01_escapes(ser))
expected_id = sha256_hex_lower(payload)
assert expected_id == event.id
# 6. verify sig per NIP-01
assert schnorr_verify(pubkey=event.pubkey, msg=event.id, sig=event.sig)
# 7. standard tag grammar
for tag in event.tags:
assert tag[0] != ""
if tag[0] == "e":
assert len(tag) >= 2
assert is_lower_hex(tag[1], 64)
if len(tag) >= 4:
assert is_lower_hex(tag[3], 64)
if tag[0] == "p":
assert len(tag) >= 2
assert is_lower_hex(tag[1], 64)
if tag[0] == "a":
assert len(tag) >= 2
# includes trailing colon for normal replaceable events
assert matches_nip01_a_format(tag[1])
# 8. contextual policy limits (optional)
if context has limits:
assert passes_limits(event, context.limits)
return VALIDATED_EVENT(event)
```

2026-01-13 22:27:59 UTC

I've just published my first NIP, "Strict Event Validation," to NostrHub. Hope it helps!
I'm relatively new to the Nostr protocol specs and am open to corrections. The NIP is meant as a starting point for discussions, not a final answer.
Comments, questions, or suggestions are welcome.
https://nostrhub.io/naddr1qvzqqqrcvypzqfx0wns3ykpna96jkjzru2y8mmwa76gs39hxaq4zmmmgepf86zq5qy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqqhwd68y6trwskk2an9de6z6anpd35kgct5d9hku7s9vy7

2026-01-13 22:21:56 UTC

- reply

How do you solve for cruising around your dyson sphere in hyperdrive without having to rely on Earth as a single point of time for timestamping though? This might be the biggest threat to Bitcoin's decentralization.

2026-01-13 20:10:54 UTC

- reply

Also ...
"No plan survives contact with the enemy."
-- Field Marshal Von Moltke
"I have never had a plan of operations."
-- Napoleon

2026-01-13 20:10:23 UTC

- reply

Montgomery's one-pager for D-Day: https://image.nostr.build/322320f7c3cec6975717919acb08b6cbbf51451b61d1a90549ea5c4c1b3dc184.jpg

2026-01-13 16:56:21 UTC

- reply

Any and all feedback welcome.
#NIP #NostrDev #StrictValidation
cc @npub1xts…kk5s

2026-01-13 15:48:29 UTC

- reply

Working on something that addresses all of the points you mentioned. Currently in protocol design stage. Feedback welcome. AMA.
https://iris.to/note12p9w7eau9565nkqzzhfytg8dz085r6kad49pccvvy5uzk4ddwp5qu03jjc

2026-01-13 08:57:53 UTC

**NIP-XX: Strict Event Validation**
This draft NIP sets clear, strict rules for validating Nostr events. It ensures every event uses the correct format: all hex codes (such as id, pubkey, and sig) in lowercase, timestamps and kinds as whole numbers (integers), tags properly structured, and invalid events rejected immediately.
The goal is to address a root issue: NIP-01 leaves some format details underspecified (for example, it describes hex as lowercase but does not strictly enforce it everywhere, and it uses "number" for created_at and kind without explicitly requiring integers). This has allowed malformed or inconsistent events to appear in the network. Strict checking helps prevent these from causing bugs, interoperability problems between apps, wasted storage on relays, and crashes in user interfaces.
I'm relatively new to Nostr and very open to feedback on this. This NIP is meant as a starting point for discussion, not a final answer. I'm especially interested in hearing where it overlaps with existing work, where it might be too strict, or where it does not fit the direction Nostr is heading or other NIPs or discussions I may have missed or misinterpreted.
cc @nprofile…xuyp @nprofile…xnfk
https://github.com/livegnik/NIPs-by-Tim/blob/master/nip-xx-strict-event-validation.md

2026-01-13 08:28:29 UTC

- reply

First thing I saw this morning when I opened Nostr. gg

2026-01-11 02:42:36 UTC

2WAY: P2P application protocol.
Users own their data, apps can talk directly to each other, and all state lives in a cryptographically secured graph that syncs with other nodes based on user-defined permissions.
AMA.
https://github.com/livegnik/2way-poc-design

2026-01-09 23:54:04 UTC

- reply

You can still use a graph offline.
https://iris.to/note1tlzzsszhk5xaghfdeuvlewajrz0hvxnsgdtln7uv7jff6zhtpdxqt4ndzx

2026-01-09 21:43:47 UTC

What if apps did not depend on a centralized backend?
I am working on 2WAY, a local-first, peer-to-peer, open-source (MIT) application protocol and backend, designed to run on practically any device. The goal is to move core infrastructure concerns out of individual apps and into a shared system layer that enforces permissions, stores state as a cryptographically secured graph in a relational database, and synchronizes that state directly between peers.
Apps focus on their data model and domain logic. The protocol handles persistence, ordering, synchronization, and trust between peers. This allows apps to work offline by default, survive node loss, and keep functioning without central servers or long-lived operators.
This enables classes of apps that are difficult or impossible to build on centralized systems. Apps where users keep control of their data instead of handing it to a provider. Apps that rely on cryptographic proofs as the source of truth rather than trusted networks or intermediaries. Apps that keep working through network splits. Apps that can interoperate without shared infrastructure or federation. Apps that do not break when a service shuts down, changes terms one-sided, or disappears.
The system is designed to fail locally and predictably under stress or abuse, with built-in resistance to Sybil attacks and denial-of-service.
This repository is a work in progress. I am currently focused on the protocol and architecture, which are about 95 percent complete, unless someone points out a fundamental flaw. The rest of the repository already defines the full system surface, including data, interfaces, security, flows, and more. The structure is in place, but these sections still need to be written and fleshed out.
Any questions, comments, or suggestions are welcome and appreciated.
Design repository with specs: https://github.com/livegnik/2way-poc-design

2026-01-09 20:55:19 UTC

- reply

https://image.nostr.build/87b1befd5be51fad6d9e55c94a81c1d451ebc6393650a55db7cc32e524b36e7b.jpg

2024-12-03 19:11:21 UTC

- reply

It's still there and has been for more than a year now ...

2024-01-07 19:43:17 UTC

Are there any groups other than Bitcoiners well-represented on here already? If so, who do I folllow?

2023-10-11 11:41:30 UTC

Will be swinging by Nostrdam tonight to say hi.

2023-08-20 12:22:27 UTC

Working on a book about decentralized identity and reputation systems.
Identity = an account on a website, email address, public key, etc.
Reputation = the graph, or network attached to any of these identifiers
Would you read it? What would you like to learn from it?

2023-07-25 00:57:10 UTC

- reply

Respeck.

2023-07-24 12:28:02 UTC

- reply

It's basically onecoin but worse. Worstcoin.

2023-07-14 22:59:55 UTC

What's the best platform to get a free ebook out with the least amount of hassle? Thanks.

2023-07-07 13:28:29 UTC

Since 'likes' don't really do much around here incentive-wise, apart from showing the receiver you liked their message (which was once the main reason for its existence), I'm going to start and try to reprogram my brain to throw less likes around. The main reason I'm acting like The Incredible Likeman(tm) on Twitter is due to its algo. My main driver for giving out so many likes on there is to add "weight" to the reputation scoring mechanism Twitter uses. That's not needed necessary on here, and so I want to get back to basics and make "like" scarce again. #Like4Real
https://nostr.build/i/829742ec89928f68bd9ffd4fccdb10cfbeda720b3a1cf1433c79e885fd5c891a.jpg

2023-07-06 12:46:07 UTC

- reply

What else could it look like on this timeline?

2023-07-06 12:31:59 UTC

- reply

Not to even mention the map that caused all this. Wtf is this even? Also note the other similar line that looks more like a shipping lane.
https://nostr.build/i/1cb9f0ca08297e920724fe399b716557e2e596482b626a709950a56e36ab8568.jpg

2023-07-06 00:48:34 UTC

- reply

Carsten Keutmann is working on a graph-based application that runs atop Nostr, which could serve as a foundation for search.
https://github.com/keutmann?tab=repositories
https://medium.com/@carstenkeutmann_96497

2023-07-04 11:27:12 UTC

- reply

Salut! o/

2023-07-04 11:06:36 UTC

- reply

Glad it helped. :)

2023-07-03 23:02:57 UTC

- reply

Seems you have to connect to one of the PSPs they've partnered with. A few of these seem to support Bitcoin, but I guess it's not the type of solution fiatjaf was hoping for..
https://support.wix.com/en/third-party-payment-providers
https://support.wix.com/en/article/connecting-bankful-as-a-payment-provider-for-cryptocurrency-wallet-and-credit-card-payments
https://support.wix.com/en/article/connecting-coingate-as-a-payment-provider-for-cryptocurrency-payments

2023-07-02 15:06:05 UTC

Thank you Elon for the free PR.

2023-07-02 15:00:56 UTC

- reply

I'll take them to our leaders if they take them with them.
https://www.youtube.com/watch?v=ETbPRUqL_HE

2023-07-02 13:51:45 UTC

twttr rn
https://nostr.build/i/90869abd4441e154624fca333eab2465c85f855fffdac93bc5278f2c0c02419e.jpg

2023-07-02 11:50:10 UTC

Working on a free ebook on decentralized identity and reputation systems. It will be the most comprehensive book on the matter to date.
Currently editing it and am at page 123 of 215.
https://nostr.build/i/704730fe598cd8b8d5897471674ae5b622a912a25788690d649bcb56f3dc5f3c.jpg

2023-07-02 11:44:57 UTC

- reply

How about PoW-based puzzle challenges (as described by Juels et al) for clients to solve (solves for embeds too?) with difficulty adjustments based on current count of connections?
Wouldn't that be easier to implement and more user friendly, while also introducing significant costs to attacking the system and little costs to legitimate users?

2023-04-13 14:38:44 UTC

- reply

🙏

2023-04-02 16:02:36 UTC

- reply

Also note how Bitcoin caused more intermediaries, not less.

2023-04-02 16:00:37 UTC

- reply

Not that we need them, but many users will surely choose to opt-in to them, as much as we may dislike that. Until someone maybe figures out how to fix the UX for the average user, which I wouldn't bet the farm on.

2023-03-11 00:22:04 UTC

What's needed for a decentralized GitHub?
I'm only familiar with the basics of Git and never really used GitHub meaningfully.
What building blocks would you say are needed for an MVP?

2023-03-10 17:51:59 UTC

- reply

What, no leverage? No yield? No reinvesting earnings into money market mutual funds?

2023-03-10 17:51:16 UTC

At what depth are dinosaur bones found and at what depth is oil found and wassup with that?

2023-03-01 15:03:28 UTC

- reply

"Hey, I sent you that email."

2023-03-01 14:50:20 UTC

LN Zaps, but for websites (think: blog articles, videos, comments, you name it).
Discuss.

2023-02-28 14:29:26 UTC

- reply

I'm waiting for a computer. Can you tell it to hurry up?

2023-02-28 14:24:17 UTC

- reply

Been thinking about drawing out the network graph along with some subsets of meta data to visualize this, but it's a ton of work that I can't prioritize right now. If someone wants to do it, feel free to grab this idea and not even credit me for it. Also feel free to drop a DM, unless you plan on traveling to China. 😅

2023-02-28 14:12:38 UTC

- reply

Thanks, I did not know that and had been looking for this info. It seems not much needs to be done here then, and that it's mostly up to the clients from here (of whom some are already on it). I might as well retract that short read given this new insight, which is still a succes in my book because I've learned something new. So, cheers! :)

2023-02-28 13:44:58 UTC

- reply

+10.

2023-02-28 00:08:51 UTC

- reply

I haven't read any of them, so I haven't been disappointed that way.

2023-02-28 00:07:48 UTC

- reply

Or instead of clients having a global timeline maybe have (another) one that only shows notes from your 1st, 2nd, and 3rd degree follows? That might help resists spam and anything considered irrelevant to the user. /my2sats

2023-02-28 00:06:07 UTC

- reply

How about an option for relays to only store messages from their users, their followers, and perhaps even their followers (third degree)? If that could be an option, I wrote a few words on it. Curious for any type of feedback.
https://medium.com/@2W/spam-filter-idea-for-nostr-ee2a8f7d192e

2023-02-27 10:34:01 UTC

- reply

Automated DCA?

2023-02-26 14:35:33 UTC

Love this beat.
https://www.youtube.com/watch?v=o6UBxAtqLKk

2023-02-26 02:52:57 UTC

Shout out to whoever runs the #[0] bot. I'm just going to go ahead and pretend it's him like the idiot that I am.

2023-02-26 02:49:04 UTC

- reply

Maybe on a timeline where he smoked weed.
https://nostr.build/i/nostr.build_5ab42bca5cdf7d77dfeab1a1a21b6c43b913d1b917073b7f13a2881cc0ce94c7.jpg

2023-02-26 02:47:13 UTC

- reply

If you'd ask me? Retention. Retention is a b*tch.

2023-02-26 02:40:13 UTC

What do you think is needed for Nostr to reach the next step in adoption?

2023-02-26 02:38:23 UTC

- reply

Me like.

2023-02-26 02:37:36 UTC

Just remembered that links don't get scrubbed off here like on some other sites. 😏

2023-02-26 01:49:48 UTC

- reply

Reminds me of the Chebika oasis in Tunisia. Good point.

2023-02-26 01:47:51 UTC

- reply

It depends. What about block rewards?

2023-02-26 01:16:25 UTC

"Growing your own food is like printing your own money."
-- Ron Finley

2023-02-26 00:33:44 UTC

- reply

If Calvin Ayre hadn't funded the movie I might recommend one right now.

2023-02-26 00:31:58 UTC

- reply

The only thing I'd like to see changed in Amethyst are the auto-translation by default and removing your own comments (@your_own_name) from the notifications.
https://iris.to/post/note1q8gydu5j527vkft7sux49xav3m8r63epyjju08j6vupy2mfu3f6qreh8mw

2023-02-26 00:30:32 UTC

- reply

Greetings from Iris.to. 🤙

2023-02-24 18:59:27 UTC

- reply

What about ..? https://medium.com/@2W/spam-filter-idea-for-nostr-ee2a8f7d192e

2023-02-24 15:09:30 UTC

- reply

Sees "1129 following".
Oh boi, here we go.

2023-02-24 15:08:54 UTC

- reply

Check out my following list. :)

2023-02-24 15:08:12 UTC

- reply

Any plans on some form of LN integration, by any chance? Or would that be something for extensions/plugins to handle?

2023-02-24 15:07:34 UTC

- reply

🙌

2023-02-24 14:36:30 UTC

- reply

Purely from an economical perspective, you might be one of the few people in the world who might be able to put a stop to it. They'll just continue until they establish jurisprudence somewhere, to then use that in other jurisdictions to get judges to make people surrender their bitcoins to them.

2023-02-24 04:34:02 UTC

- reply

Real estate.

2023-02-24 03:46:44 UTC

- reply

I wish you many more withdrawals. And I mean that in a good way.

2023-02-22 12:56:31 UTC

Still looking for feedback. 🤙
https://medium.com/@2W/spam-filter-idea-for-nostr-ee2a8f7d192e

2023-02-21 00:18:51 UTC

- reply

Random question: What's the #1 thing you've learned from everything that happened over the past couple of months?

2023-02-20 15:18:40 UTC

- reply

It only applies to the global timeline, and it's more focused on how relays work and what data they store.

2023-02-20 14:16:39 UTC

Spam Filter Idea for Nostr
https://medium.com/@2W/spam-filter-idea-for-nostr-ee2a8f7d192e

2023-02-20 13:00:20 UTC

#[0] Shout out for the performance improvements. 🤙

2023-02-20 12:59:21 UTC

- reply

I'll 1up by saying satoshis are the only unit that exist in Bitcoin. 🤡🍿

2023-02-20 12:57:35 UTC

- reply

You could still go paid after that, but wouldn't it allow for a way to solve for spam that's affordable to most / more?

2023-02-20 12:57:00 UTC

If a Nostr relay had the ability to only store messages from its users and those they follow (web of trust-like graph), could that solve for spam without going paid?

2023-02-15 20:25:13 UTC

I love Nostr, think it's awesome in all sorts of ways. I probably won't be using DMs on it in the foreseeable future though, given all meta data is public. I'd rather have a company try and keep it secure with the chance of it leaking increasing by the day than to broadcast it in public. Most preferred solution would be e2e encrypted sockets between clients, somehow, some day.

2023-02-15 20:08:45 UTC

- reply

Works on doze. +1

2023-02-15 20:08:35 UTC

- reply

loik

2023-02-15 20:08:25 UTC

ctrl+enter test

2023-02-15 19:59:37 UTC

Got links about existing solutions to mitigate spam on Nostr? Thanks in advance!
(already found related issues on Nostr and Damus Github)

2023-02-15 19:57:12 UTC

- reply

Truth is stranger than Bitcoin.

2023-02-13 08:40:09 UTC

Gm! 🤙
Looking for something to read/learn about existing solutions to mitigate spam on Nostr.
I found issues on the Damus and Nostr Github with suggestions in them, but was hoping someone could tell me how it works in practice without having to sift through all the code. I would love to run a relay and go through the code myself, but I have too much other stuff to focus on right now, unfortunately. However, I am finding the time to write an article about Nostr and a possible way to add relatively simple and efficient spam and Sybil-resistance that I'll publish here (first!) when it's done. That's why I'm looking for more info to make sure I get things right and to hopefully not waste anyone's time.
Hope it'll help, and thanks for yours in advance!

2023-02-01 15:18:45 UTC

- reply

Unsmoked means you can smoke it, right?