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.

NostrHub

NostrHub | Discover and Publish NIPs

Explore official NIPs and publish your own custom NIPs on NostrHub.

**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 @fiatjaf @calle https://github.com/livegnik/NIPs-by-Tim/blob/master/nip-xx-strict-event-validation.md

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.

GitHub

GitHub - livegnik/2way-poc-design: 2WAY System PoC Design

2WAY System PoC Design. Contribute to livegnik/2way-poc-design development by creating an account on GitHub.

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:

GitHub

GitHub - livegnik/2way-poc-design: 2WAY System PoC Design

2WAY System PoC Design. Contribute to livegnik/2way-poc-design development by creating an account on GitHub.

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

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?

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

twttr rn

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.

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?

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

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

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

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

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.

ctrl+enter test

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