Nostr notes by signet

Anyone can run a Nostr relay. Popular relay software includes ...

2026-07-20T16:25:37Z

Anyone can run a Nostr relay. Popular relay software includes strfry, nostr-rs-relay, and relayer. Pick one, configure it, run it. You're now part of the network.

Why run your own? Guaranteed storage for your events, control over who can post, no dependency on third parties, and educational experience. Relays need persistent storage, bandwidth, and uptime. A small relay for personal use is cheap, while a public relay serving thousands of users requires more resources. You can run a public relay, a private one, or something in between. Pay-to-post relays monetize access, community relays serve specific groups. Relays are infrastructure, and the more diverse relay operators, the more resilient the network.

Reporting abuse on Nostr works differently than centralized ...

2026-06-19T17:20:36Z

Reporting abuse on Nostr works differently than centralized platforms. NIP-56 defines a reporting mechanism where you publish an event tagging the offending content and a reason. This report is visible to relay operators and tools that aggregate reports.

But reports don't guarantee action. There's no central moderation team, and each relay decides its own policies. Some relays ignore reports while some take action quickly. Community relays might have stricter moderation while public relays might have none.

Reporting is a signal, not a command. It informs those who want to moderate but doesn't force anything. Combined with muting, you can curate your experience even if nobody else acts.

Nostr supports content warnings through tags. Add a ...

2026-05-25T17:08:43Z

Nostr supports content warnings through tags. Add a "content-warning" tag to your event with a reason, and clients that understand this will hide the content behind a click-through. Useful for spoilers, sensitive topics, or anything that needs context before viewing.

This is voluntary, and clients choose whether to respect it, though most do. It's a social convention backed by protocol. You're signaling to readers that they should have a choice before seeing this content. Good citizenship in a decentralized network. No one can force you to use content warnings, but they're a useful tool for being considerate while still posting freely.

Signet logs what it does: every connection attempt, every signing ...

2026-05-11T17:26:32Z

Signet logs what it does: every connection attempt, every signing request, every approval or denial. This gives you an audit trail of what happened and when.

Why care? If something seems wrong, logs tell the story. Did a client request something unexpected? Did a connection come from somewhere unusual? Check logs periodically and look for patterns you don't recognize. A client signing things at 3am when you were asleep might indicate a compromised client or misconfigured auto-approve. Logs are also useful for debugging connection issues. If a client can't connect, the logs show why. Visibility into your signer's activity is part of maintaining security.

Nostr has privacy limitations. Know them. Your posts are public ...

2026-05-08T16:15:50Z

Nostr has privacy limitations. Know them. Your posts are public by default, and everyone can see them. DMs hide content but metadata is visible (who talked to whom, when). Gift wrapping helps but isn't universal.

Relays see your IP address. They see your pubkey. They can log all your activity. Your follow list is public. Your profile is public. Your relay list is public.

If you need strong privacy, layer additional tools. Tor for IP hiding. Separate keys for separate activities. Careful operational security. Nostr is censorship-resistant, not privacy-first. Design your usage accordingly.

Nostr is open and anyone can contribute. You can run a relay and ...

2026-04-29T16:43:46Z

Nostr is open and anyone can contribute. You can run a relay and operate infrastructure others can use, build a client and create better ways to interact with the protocol, or write a NIP to propose new features and standards. Creating content by posting interesting things helps grow the network.

Helping new users by answering questions, writing guides, and making onboarding smoother is valuable. If you find something broken, report bugs to the developers. Most projects are open source on GitHub, so you can contribute code directly.

There's no company to apply to and no gatekeepers. If you build something useful, people will use it.

REQ and EVENT are the core WebSocket messages. REQ requests ...

2026-04-24T16:06:25Z

REQ and EVENT are the core WebSocket messages. REQ requests events from a relay. You send a subscription ID and filters, and the relay responds with matching events. EVENT sends an event to a relay, for publishing your own events or when relays push events matching your subscription.

CLOSE ends a subscription. EOSE signals "end of stored events" and the start of live streaming. OK acknowledges event acceptance (or rejection).

That's basically it. The protocol is simple. Open a WebSocket, send these messages, handle responses. Everything else is built on this foundation.

Your signer is only as secure as the device it runs on. Keep the ...

2026-04-08T16:17:01Z

Your signer is only as secure as the device it runs on. Keep the operating system updated, enable full-disk encryption, use a strong login password, and don't install random software.

If your signer runs on a dedicated device, even better. It has one job, which means a smaller attack surface and fewer ways in. Consider network segmentation too, since your signer doesn't need to be on the same network as your daily browsing. A separate VLAN or even a separate physical network adds isolation.

Physical security matters too. If someone can walk up to your server and plug in a USB stick, software security is moot. Each layer an attacker has to get through increases your safety.

Your follow list is a kind 3 event. It contains p tags listing ...

2026-04-06T15:52:33Z

Your follow list is a kind 3 event. It contains p tags listing the public keys of everyone you follow, and when you follow or unfollow someone, your client publishes a new kind 3 replacing the old one. This list is public, so anyone can see who you follow. There's no private follow option in the base protocol.

Clients use your follow list to show your feed by fetching events from the pubkeys you follow. Some relays also use it to prioritize which events to store or serve. Because follows are stored in events you sign, you can easily export them. Switch clients, and your follows come with you. No need to rebuild your social graph from scratch.

Every Nostr event has a "kind" that defines what it is. ...

2026-04-03T15:41:16Z

Every Nostr event has a "kind" that defines what it is. Kind 0 is your profile metadata, kind 1 is a text note (the basic post), kind 3 is your follow list, kind 4 is an encrypted DM, and kind 7 is a reaction. There are dozens more covering zaps, reposts, long-form content, badges, relay lists, and more. Each NIP can define new kinds for new functionality.

When an app asks your signer to sign an event, the kind tells you what you're approving. A request to sign kind 1 is a post, while a request to sign kind 0 is changing your profile. Signers can use this for permissions: auto-approve kind 1, require manual approval for kind 0. Understanding kinds helps you understand what apps are doing with your identity.

NIP-42 lets relays authenticate clients. The relay challenges ...

2026-04-01T16:07:48Z

NIP-42 lets relays authenticate clients. The relay challenges you, you sign a response with your key, and the relay now knows your pubkey and can apply policies.

Use cases include paid relays checking payment status, private relays limiting access, and rate limits based on identity. Authentication is optional, and many relays don't require it. When they do, NIP-46 compatible clients handle it transparently.

With Signet, auth challenges become signing requests. Your signer signs the auth event, proving your identity to the relay. Auth adds a layer of identity to relay connections while keeping keys secure.

Bridge bots connect Nostr to other platforms. They mirror ...

2026-03-30T16:07:46Z

Bridge bots connect Nostr to other platforms. They mirror content. A bridge might post your tweets to Nostr, or post Nostr content to Telegram, or sync across multiple protocols.

Bridges help during migration. Your audience on one platform can see you on another without switching immediately. Setting up a bridge often requires API access to both platforms. Nostr is open, but other platforms might have restrictions.

Some bridges are public services while some are self-hosted tools. Quality and reliability vary. Bridges are transitional. Eventually, you might not need them. But while building presence on Nostr, they help maintain reach.

There's no key revocation on Nostr. If your key is ...

2026-03-27T15:55:59Z

There's no key revocation on Nostr. If your key is compromised, it's compromised forever. There's no central authority to tell "this key is no longer valid."

You can stop using the key. You can tell people it's compromised. But the attacker can still sign valid events with it. This is the tradeoff for decentralization. No authority to revoke means no authority to censor.

Mitigate by protecting keys well. Use remote signing. Keep backups secure. If compromise happens, start fresh with a new key and notify your followers through other channels.

Some clients are local-first. They store events on your device, ...

2026-03-25T16:13:20Z

Some clients are local-first. They store events on your device, not just on relays. You can browse your feed offline, and data syncs when you reconnect.

This has advantages: faster loading, works without internet, and your data exists locally, not just on servers you don't control. Downsides include using device storage, syncing can be complex, and different devices might have different data.

Local-first is a design philosophy, and not all clients follow it. But it aligns well with Nostr's values of your data, your device, your control. If offline access matters to you, look for clients that emphasize local storage.

Nostr has encrypted direct messages, but understand the ...

2026-03-23T16:02:23Z

Nostr has encrypted direct messages, but understand the limitations. Kind 4 DMs encrypt the content so only you and the recipient can read it, using your private keys to derive a shared secret.

But metadata isn't hidden. Everyone can see that you sent a message to someone, and when. The relay knows, anyone watching knows, and only the content is private. NIP-44 improves the encryption scheme and newer clients are adopting it, but the metadata problem remains. For truly private communication, Nostr DMs may not be enough. They're better than public posts, but they're not Signal. Use them knowing what they do and don't protect.

There are three ways to sign Nostr events. Pasting your nsec ...

2026-03-20T15:47:28Z

There are three ways to sign Nostr events.

Pasting your nsec gives the app full access to your private key. It's fast and simple, but it means you're trusting that app completely, and if the app is malicious or gets compromised, your key is gone. Browser extensions like nos2x and Alby keep your key in the extension rather than the web app. The app requests signatures and the extension signs, giving you better isolation, but your key is still in browser memory on a device connected to the internet.

Remote signing via NIP-46 means your key lives on separate hardware you control. Apps request signatures over Nostr relays, and the key never touches the app or even your daily-use device. It's the most secure option with slightly more setup. Pick based on your threat model, but for keys that matter, remote signing is worth the effort.

Nostr is a protocol, not a platform. The difference matters. A ...

2026-03-18T16:09:48Z

Nostr is a protocol, not a platform. The difference matters. A platform is controlled by a company that sets the rules, owns the data, and can change things whenever they want. Users are guests.

A protocol is a shared language. Anyone can build software that speaks it, no permission needed, no company in control. HTTP is a protocol, and the web is built on it, but no one owns HTTP. Email is a protocol, and Gmail and Outlook compete on features, but they speak the same language. Nostr is the same idea for social media. Clients compete on user experience, relays compete on reliability, but they all speak Nostr, and users can move freely between them.

A Nostr keypair is just random numbers with math applied. ...

2026-03-16T16:07:32Z

A Nostr keypair is just random numbers with math applied. Generate 32 random bytes. That's your private key. Derive the public key using elliptic curve multiplication on secp256k1. Done.

The security comes from the randomness. If someone could guess your random bytes, they'd have your key, so the random source matters. Use your operating system's cryptographic random generator, not something you cooked up. Most people use a client or tool to generate keys, and under the hood, it's calling a proper random source and doing the math. Nothing secret about the algorithm. All the security is in those 32 random bytes. Keep them random. Keep them secret.

Nostr supports user-defined lists. You can create lists of people ...

2026-03-13T15:47:25Z

Nostr supports user-defined lists. You can create lists of people like close friends, experts, or interesting accounts. Or lists of events like bookmarks, favorites, or read later.

Lists are kind 30000 (for people) or kind 30001 (for events). They're parameterized replaceable, so you can have multiple named lists. Some clients surface lists in the UI, letting you follow a list to see its members' content or share lists with others.

Lists help manage information overload. Instead of one big follow list, create sublists for different contexts. Check your tech list when you want tech content. It's a power-user feature, but increasingly supported.

Your Nostr feed is built from events by people you follow. ...

2026-03-11T15:52:45Z

Your Nostr feed is built from events by people you follow. Clients fetch posts from the pubkeys in your follow list. They might also include replies, reposts, and reactions. The exact mix varies by client.

There's no algorithmic timeline manipulating what you see. Events appear in chronological order, or however you configure your client to sort them. Some clients offer algorithmic feeds as an option, and Primal has caching and recommendation features. But you can always return to a pure chronological feed.

You control what you see. Follow more people, see more content. Follow fewer, see less. Simple cause and effect.

Nostr supports long-form content through kind 30023 events. These ...

2026-03-09T16:01:59Z

Nostr supports long-form content through kind 30023 events. These are for articles, blog posts, and essays, longer than a microblog post, with a title, summary, and potentially markdown formatting.

They're parameterized replaceable events, meaning you can update your article by publishing a new version with the same identifier. The latest version wins. Some clients specialize in long-form content while others display it alongside regular posts. The event is just data; how it's presented is up to the client. Writers can publish directly to Nostr without a traditional blog platform, readers follow them like any other account, and the content lives on relays, signed and verifiable.

📦 Signet commit Merge pull request #43 from ...

2026-03-07T01:04:57Z

📦 Signet commit

Merge pull request #43 from vcavallo/install-ubuntu-24-fix

7c79aa0
https://github.com/Letdown2491/signet/commit/7c79aa0f334f661c709705435179b1ac9c2116d5

📦 Signet commit Remove hardcoded sqlite prebuild-install step ...

2026-03-07T01:04:56Z

📦 Signet commit

Remove hardcoded sqlite prebuild-install step

f44b8e1
https://github.com/Letdown2491/signet/commit/f44b8e1f32d5895ebc06d0ce7b6c92300d90748e

Your Nostr profile is a kind 0 event. The content field contains ...

2026-03-06T15:41:01Z

Your Nostr profile is a kind 0 event. The content field contains JSON with your display name, about text, picture URL, banner, and other metadata. When you update your profile, you publish a new kind 0 that replaces the old one.

Kind 0 is a "replaceable event," meaning only the most recent one counts. Relays should delete older versions, though not all do. Because it's just an event, updating your profile requires a signature. With a remote signer, you'd approve this separately from regular posts, and some people set their signer to require manual approval for kind 0 changes since profile updates are sensitive. Your profile is public data, and anyone can see it. Plan accordingly.

Nostr communities are like subreddits or forums. A community has ...

2026-03-04T15:47:40Z

Nostr communities are like subreddits or forums. A community has a definition (kind 34550) with name, description, rules, and moderators. Posts to the community reference it with an a tag.

Moderators can approve or reject posts. Approved posts appear in the community feed while rejected ones don't. This creates moderated spaces within the broader Nostr network, allowing community norms without imposing them on everyone.

Community support varies by client. Some have full-featured community browsing while others ignore communities entirely. It's an opt-in layer of structure for those who want it.

Signet lets you configure what gets auto-approved. By default, ...

2026-03-02T15:45:04Z

Signet lets you configure what gets auto-approved. By default, you might want to approve every signing request manually, but that gets tedious for routine actions like posting and reacting.

You can set policies: auto-approve kind 1 (posts) and kind 7 (reactions) from a trusted client, while requiring manual approval for kind 0 (profile changes) or kind 4 (DMs). Different keys can have different policies. A low-stakes throwaway key might auto-approve everything, while your main identity might require approval for sensitive actions. The goal is reducing friction for normal use while keeping control over what matters. Tune policies to match how you actually use each key.

Hardware security modules can protect Nostr keys. A hardware key ...

2026-02-27T15:40:03Z

Hardware security modules can protect Nostr keys. A hardware key like YubiKey or Ledger could store your nsec. Signing happens on the device, and the key never leaves protected hardware.

This is higher security than a file on disk. Even if your computer is compromised, the attacker can't extract the key. Support is limited, and not all clients work with hardware keys. Integration often requires custom tooling.

For most users, a remote signer like Signet provides good security without specialized hardware. For high-value keys or high-threat environments, hardware adds another layer. Match security tools to your actual risks.

Relays can rate limit you. Publish too many events too fast, the ...

2026-02-25T16:07:33Z

Relays can rate limit you. Publish too many events too fast, the relay might reject them. Open too many subscriptions, the relay might drop some.

Rate limits prevent abuse. Spammers can't flood the relay, and misbehaving clients can't consume unlimited resources. Limits vary by relay. Some are generous, some are strict. Paid relays might have higher limits.

If you're building an app, handle rate limit errors gracefully. Back off and retry. Don't assume unlimited access. For normal usage, you won't hit rate limits. For automation and bots, design with limits in mind.

Most Nostr software is open source. You can read the code, verify ...

2026-02-23T15:50:48Z

Most Nostr software is open source. You can read the code, verify what it does, audit it for security, fork it, and modify it. This transparency builds trust. You're not relying on a company's word. You can check yourself.

Open source also means community development. Bugs get fixed by anyone who finds them, and features get added by anyone who needs them. The downside is that quality varies. Some projects are well-maintained, some are abandoned, and some are one-person efforts.

But the ecosystem as a whole benefits from openness. Good ideas spread and bad ideas get exposed. Trust, but verify. With open source, you can.

Your nsec is your Nostr identity. Think of it like this: your ...

2026-02-20T15:39:57Z

Your nsec is your Nostr identity.

Think of it like this: your npub is your username, anyone can see it. Your nsec is your password, except you can never change it.

If someone gets your nsec, they become you. They can post as you, delete your content, impersonate you forever. There's no "reset password" button.

Guard it accordingly.

Mentioning someone on Nostr uses p tags. When you reference ...

2026-02-18T15:56:09Z

Mentioning someone on Nostr uses p tags. When you reference another user in a post, your client adds a "p" tag with their pubkey. This creates a link and notifies them. The mention might appear as their display name or npub in the post content, but the p tag is what matters for notifications and indexing.

Clients request events that mention your pubkey to show your notifications, and relays index p tags for this purpose. You can mention someone without them following you, and they'll see the notification if their client shows mentions. They can mute you if they don't want to.

It's direct, peer-to-peer notification with no platform mediating.

Every Nostr event has the same basic structure. The id is a hash ...

2026-02-16T15:44:27Z

Every Nostr event has the same basic structure. The id is a hash of the event content that serves as a unique identifier. The pubkey is who created it (your public key), created_at is a Unix timestamp for when it was made, kind defines what type of event it is (1 for posts, 0 for profile, etc.), tags contain metadata like mentions, references, and hashtags, content holds the actual payload (text for posts, JSON for profiles), and sig is the cryptographic signature proving you made it.

The id is calculated by hashing the other fields (except sig) in a specific order, and the signature covers this hash. Change anything and the signature breaks. Simple structure, infinite possibilities. Every feature in Nostr is just a different kind with different tag conventions.

Security starts with threat modeling. Who are you protecting ...

2026-02-13T15:46:55Z

Security starts with threat modeling. Who are you protecting against?

Random opportunists are stopped by basic hygiene: don't reuse passwords, don't paste nsecs into sketchy sites. Targeted attackers require more care, including separate devices, remote signing, and operational security. State-level adversaries are a different ballgame entirely with air-gapped systems and serious OpSec, but they're probably outside most people's threat model.

Most Nostr users need protection against the first two, and remote signing handles a lot of it. Your keys aren't on the devices you use daily, so compromising those devices doesn't give up your identity. Know your threats and scale your defenses accordingly. Don't under-protect, but don't over-complicate either.

Bookmarks save events for later. Kind 10003 (public) or kind ...

2026-02-11T16:05:36Z

Bookmarks save events for later. Kind 10003 (public) or kind 30001 with d=bookmark (private) store references to events you want to keep. Public bookmarks are visible to everyone while private bookmarks are encrypted.

When you bookmark a post, your client adds it to your bookmark list. You can retrieve it later without searching. Unlike likes, which are social signals, bookmarks are personal organization. Save a thread you want to read later or archive reference material.

Check if your client supports bookmarks since not all do. But the protocol allows it.

Never rely on a single relay. If your only relay goes offline, ...

2026-02-09T15:59:45Z

Never rely on a single relay. If your only relay goes offline, you disappear from Nostr. If it gets hacked, your event history could be lost. If the operator decides to ban you, you're cut off.

Using multiple relays means redundancy. Your events exist in multiple places, readers can find you through any of them, and there's no single point of failure. Five to ten relays is a reasonable number, with a mix of large public relays and smaller community ones, and maybe a paid relay for reliability. More relays means more bandwidth and slightly slower posting, but the resilience is worth it. Don't put all your eggs in one basket.

Nostr started in 2020, created by fiatjaf. The idea was simple: ...

2026-02-06T15:43:23Z

Nostr started in 2020, created by fiatjaf. The idea was simple: what if social media used public key cryptography instead of usernames and passwords? What if the network was a protocol anyone could build on?

It gained traction slowly at first, with a few developers building clients and a few relays coming online. The community was small but dedicated. Adoption accelerated in late 2022 and 2023 as high-profile users joined, client development picked up, and the protocol matured through real-world usage. Nostr isn't finished. NIPs are still being proposed, clients are still improving, and the ecosystem is young and evolving. But the foundation is solid: simple protocol, strong cryptography, decentralized architecture. The rest is building.

Nostr makes censorship expensive and inconvenient. There's no ...

2026-02-04T15:48:18Z

Nostr makes censorship expensive and inconvenient. There's no central server to shut down, no company to pressure, and no database to seize. Just a protocol that anyone can implement.

To silence someone on Nostr, you'd need to convince every relay to refuse their events. Given that anyone can run a relay, that's practically impossible. Individual relays can moderate and individual clients can filter, but network-wide censorship requires controlling the entire network, which is decentralized by design. This doesn't mean anything goes. Communities can set norms and tools exist for muting and blocking, but the choice is distributed, not centralized. Censorship resistance isn't about enabling bad content. It's about ensuring no single entity controls the discourse.

Relay reliability varies widely. Some relays are run ...

2026-02-02T15:40:13Z

Relay reliability varies widely. Some relays are run professionally with high uptime, while some are hobby projects that go down unexpectedly.

Signs of a reliable relay include consistent uptime, fast responses, active maintenance, and clear policies. Red flags include frequent downtime, slow connections, no contact info, and an abandoned feel. Paid relays tend to be more reliable since the payment funds infrastructure and filters out casual abuse.

Check relay status tools to see what's up, what's down, and what's historically stable. For your critical relays (the ones in your bunker URL, for example), reliability matters more. Choose carefully.

📦 Signet commit Migrated to React 19/Vite 7 and upgrade all ...

2026-02-01T06:36:53Z

📦 Signet commit

Migrated to React 19/Vite 7 and upgrade all dependencies to the latest versions. Additionally, fixed some outstanding bugs, fixed a couple of security vulnerabilities, and implemented some performance improvements across signet-daemon, signet-ui, and signet-android

c6f6fa0
https://github.com/Letdown2491/signet/commit/c6f6fa0ee836f1840fd4ed21cec234824c2c237d

Every Nostr event has a created_at timestamp. It's a Unix ...

2026-01-30T15:38:58Z

Every Nostr event has a created_at timestamp. It's a Unix timestamp in seconds, and when you publish, your client sets this to roughly the current time.

Relays can reject events with timestamps too far in the future, and some reject events too far in the past. This prevents backdating or future-dating abuse. But timestamps are self-reported, and a sophisticated actor can manipulate them within whatever bounds relays accept. Don't rely on timestamps for strong guarantees about when something was actually created. For ordering events, timestamps are usually good enough. For proving exact timing, you'd need external verification. Nostr timestamps are useful, not authoritative.

The gossip model is how Nostr spreads events efficiently. You ...

2026-01-28T15:37:18Z

The gossip model is how Nostr spreads events efficiently. You don't need to be connected to every relay. Events propagate. Someone posts to their relays, those relays send to connected clients, and clients might republish to their relays.

This means your content spreads beyond where you directly post. Coverage increases organically. But it's not guaranteed. If you post to an isolated relay that nobody else uses, the event might stay there.

Publishing to multiple well-connected relays gives events the best chance to propagate. The network does the rest.

The outbox model is how clients find where people publish. When ...

2026-01-26T15:33:27Z

The outbox model is how clients find where people publish. When you follow someone, their relay list (NIP-65) tells you where they write, and your client connects to those relays to fetch their content. When you publish, your relay list tells others where to find you.

This is more efficient than connecting to every possible relay. You only connect to relays where relevant people actually post. Clients that implement the outbox model handle this automatically. You follow someone, the client finds their relays, and you see their posts.

It's a key piece of making Nostr scale. Follow anyone, discover their relays, stay connected.

Relays see a lot. They see your IP address when you connect, what ...

2026-01-23T15:30:10Z

Relays see a lot. They see your IP address when you connect, what events you publish, and what events you request. They can correlate this to build a profile of your activity.

Using multiple relays doesn't fully solve this. You're spreading information, but each relay still sees their piece. Tor can hide your IP from relays and some clients support it, but Tor adds latency and complexity.

The fundamental tradeoff is that relays are untrusted infrastructure that you depend on. They can't forge your posts, but they can observe your behavior. Pick relays run by people or organizations you have some reason to trust, or run your own.

Nostr and ActivityPub are both decentralized, but differently. ...

2026-01-21T15:36:53Z

Nostr and ActivityPub are both decentralized, but differently. ActivityPub (Mastodon, etc.) uses servers that federate. Your account lives on one server, that server talks to others, and if your server goes down, your account is stuck.

Nostr uses keypairs and dumb relays. Your identity is your key, not your server. Relays just store and forward. Switch relays freely. No single point of failure for your account.

ActivityPub has richer features out of the box while Nostr is simpler but more resilient. Both are better than centralized platforms. Different tradeoffs. Try both if you want.

📦 Signet commit Implemented switch_relays method e83318a ...

2026-01-21T04:02:11Z

📦 Signet commit

Implemented switch_relays method

e83318a
https://github.com/Letdown2491/signet/commit/e83318a77c539a4d21e71f6bff6144f48b892fe5

NIP-26 defines delegation: letting another key sign on your ...

2026-01-19T15:30:27Z

NIP-26 defines delegation: letting another key sign on your behalf. You create a delegation token, signed by your main key, saying "this other pubkey can sign kind 1 events for me until this timestamp." The delegate can then post as you, and clients verify both the post signature and the delegation token.

Use cases include bots, teams, and scheduled posting. Your main key stays secure while a less-privileged key handles day-to-day posting. Delegation has limits: you specify what kinds of events the delegate can create and for how long, and the delegate can't exceed those bounds. Not all clients support NIP-26 yet, so check before relying on it, but it's a powerful tool for managing access without sharing your actual nsec.

📦 Signet commit Added Trusted Relay Assertions scoring to ...

2026-01-18T01:02:06Z

📦 Signet commit

Added Trusted Relay Assertions scoring to relays in signet-ui sidebar, system status widgets, and NostrConnect connection screens to ensure users know if a relay can be considered trustworthy.

ff910f9
https://github.com/Letdown2491/signet/commit/ff910f947e8ad34b1052a7cc9bc87821724e0f67

📦 Signet commit Implemented NIP-49 key encryption, plus ...

2026-01-17T18:16:02Z

📦 Signet commit

Implemented NIP-49 key encryption, plus additional UI tweaks and bugfixes.

c9b5c39
https://github.com/Letdown2491/signet/commit/c9b5c39491e16bbab72e8f7997860d187de2f5cb

Replies on Nostr use e tags to reference parent events. When you ...

2026-01-16T15:27:58Z

Replies on Nostr use e tags to reference parent events. When you reply to a post, your event includes an "e" tag pointing to the original event ID, and clients use this to build threads. Multiple reply levels create trees with the root post, then replies, then replies to replies. Tags indicate where in the tree a post belongs.

Different clients display threads differently. Some show all replies while some collapse deep threads. The data is the same, but presentation varies.

Understanding threading helps when something looks off. If a reply seems orphaned or misplaced, it might be a client rendering issue, not a data problem.

Most major Nostr clients now support NIP-46 remote signing: ...

2026-01-14T15:29:58Z

Most major Nostr clients now support NIP-46 remote signing: Damus, Amethyst, Primal, Coracle, Snort, Nostrudel, and others. The list keeps growing.

Look for "Login with bunker" or "Remote signer" or "NIP-46" in the login options. Some apps call it "nsecBunker" after the original implementation. If an app only offers "paste your nsec" with no signer option, that's a red flag for security-conscious users. Either the app hasn't implemented NIP-46 yet, or the developers don't prioritize key security. The ecosystem is moving toward remote signing as the default, and apps that don't support it are falling behind.

📦 Signet commit Additional memory handling improvements in ACL ...

2026-01-13T03:58:13Z

📦 Signet commit

Additional memory handling improvements in ACL cache and AdminCommandService

3863f21
https://github.com/Letdown2491/signet/commit/3863f215926c57c7d46ed4efaed24c7a412525e6

Global feeds show everything a relay has. Instead of filtering to ...

2026-01-12T15:30:06Z

Global feeds show everything a relay has. Instead of filtering to people you follow, a global feed shows all kind 1 events. Everything anyone is posting.

This can be overwhelming. On a busy relay, the global feed scrolls fast with lots of noise. Global feeds are useful for discovery, letting you see what the broader network is talking about and find new people to follow. Some clients let you filter global feeds by hashtag or other criteria, which makes them more useful.

Global doesn't mean literally every post on Nostr. It means everything on the relays you're connected to. Different relays, different global views.

📦 Signet commit Minor bugfix release to fix an issue with ...

2026-01-12T06:22:21Z

📦 Signet commit

Minor bugfix release to fix an issue with biometric unlock not respecting user-defined lock times on Android

b501f12
https://github.com/Letdown2491/signet/commit/b501f121e953de2507474d4f378f8cc444541641

📦 Signet commit Add LogsPanel UI components for daemon logs ...

2026-01-12T01:00:44Z

📦 Signet commit

Add LogsPanel UI components for daemon logs

08e5cc6
https://github.com/Letdown2491/signet/commit/08e5cc6f14411b005fe334df3194316bd3b9a9bb

📦 Signet commit Fixed memory leak in AdminCommandService and ...

2026-01-12T01:00:44Z

📦 Signet commit

Fixed memory leak in AdminCommandService and SSE event handlers

479cd0a
https://github.com/Letdown2491/signet/commit/479cd0a4d186b175d5febbed8c9cf127d7e28aef

📦 Signet commit Bug fixes, security improvements, improved ...

2026-01-11T21:10:12Z

📦 Signet commit

Bug fixes, security improvements, improved memory allocation, and general UX improvements in web UI and Android clients

7a0f222
https://github.com/Letdown2491/signet/commit/7a0f2223b7ad8cb26b307d27334ce69527729780

📦 Signet commit Added NostrConnect support. Implemented new ...

2026-01-09T18:18:27Z

📦 Signet commit

Added NostrConnect support. Implemented new inactivity lock to autolock keys and autosuspend app permissions after user defined period. Additional work on connection health monitoring. Updated documentation.

11b890e
https://github.com/Letdown2491/signet/commit/11b890e5010c430d174a5f9b48320ec87ea034b3

Nostr is automation-friendly. Events are just JSON, signing is ...

2026-01-09T15:28:12Z

Nostr is automation-friendly. Events are just JSON, signing is straightforward with libraries, and relay connections are standard WebSockets. This means bots are easy to build, including scheduled posts, automated responses, data aggregation, and cross-posting. If you can script it, you can automate it on Nostr.

Signet supports automation through its CLI. Import a key, sign events programmatically, and integrate into pipelines. Remote signing is especially useful for automation. Your automation scripts request signatures from Signet, and you can set auto-approve policies for routine automated actions.

The protocol doesn't distinguish human posts from automated ones. Use this power responsibly.

📦 Signet commit Added admin event logging to track key ...

2026-01-08T00:57:25Z

📦 Signet commit

Added admin event logging to track key lock/unlock, app suspend/resume, etc. Improved pool tracking to prevent stale SSE connections from not restarting during long sleep/wake cycles. Replaced relays widget with system status widget. Added option kill switch to send daemon commands via NIP-04 and NIP-17 DMs from user-defined admin npub. Updated documentation.

a0deae7
https://github.com/Letdown2491/signet/commit/a0deae76709ea7bf947563bf818f056023d5104e

Nostr keys come in two formats: hex and bech32. Hex is the raw ...

2026-01-07T15:29:37Z

Nostr keys come in two formats: hex and bech32.

Hex is the raw format: 64 characters using 0-9 and a-f. This is what the cryptography actually uses. Bech32 is the human-readable format that starts with npub for public keys and nsec for private keys, and includes a checksum to catch typos. An npub1abc... is the same key as a 64-character hex string, just encoded differently.

Use bech32 when sharing or storing keys since the prefix makes it obvious what you're looking at and the checksum prevents errors. Use hex when interfacing with low-level tools or libraries that expect it. Most apps accept both, and Signet accepts both.

📦 Signet commit Improvement bunker URI workflow with QR codes ...

2026-01-06T03:58:08Z

📦 Signet commit

Improvement bunker URI workflow with QR codes and expiring secrets; improved permission approval process; ability to lock/unlock keys and suspend app permissions with additional time-based suspension.

5227ca5
https://github.com/Letdown2491/signet/commit/5227ca51881c53d51cba4f89eb28f701e0ffbf01

Spam is a challenge for Nostr. Anyone can create a keypair and ...

2026-01-05T15:28:19Z

Spam is a challenge for Nostr. Anyone can create a keypair and anyone can post. Low barrier to entry means spammers can create endless accounts.

Defenses exist. Proof of work raises the cost of bulk posting. Paid relays filter out casual spam. Web of trust can prioritize content from people your follows follow. Clients can implement spam filters, with some hiding posts from accounts with no followers and some using reputation systems.

No solution is perfect, and spam is an ongoing arms race. But the decentralized architecture means different relays can try different approaches, and what works will spread. Your personal defense: mute aggressively and use relays with good policies.

📦 Signet commit Brought web UI and Android app UI closer in ...

2026-01-03T06:18:01Z

📦 Signet commit

Brought web UI and Android app UI closer in line. Fixed approval/denial bug in Recents widget. Additional UI tweaks and bug fixes.

e32d1c8
https://github.com/Letdown2491/signet/commit/e32d1c8bc143d5b7db6dc9344cdd1faaf59183e0

📦 Signet commit Fixed an issue that prevented the Android app ...

2026-01-02T21:09:08Z

📦 Signet commit

Fixed an issue that prevented the Android app from detecting version number.

ee0b3d1
https://github.com/Letdown2491/signet/commit/ee0b3d105cd8684fcc04f25f70fde69043ee36f7

📦 Signet commit Update http-proxy to fix DoS CVE, added QR ...

2026-01-02T18:43:37Z

📦 Signet commit

Update http-proxy to fix DoS CVE, added QR codes to each IP the daemon detects for easier Android app setup, labeled Tailscale IPs as such for differentiation, updated build scripts and Dockerfiles to eliminate build warnings and daemon inconsistencies.

6693383
https://github.com/Letdown2491/signet/commit/66933837e1a482df88185c06e7089c6e858cda7b

Nostr Connect is another term for NIP-46 remote signing. You ...

2026-01-02T15:26:03Z

Nostr Connect is another term for NIP-46 remote signing. You might see "Connect with Nostr" buttons on apps, and this usually means NIP-46. The app wants to connect to your signer.

The flow is to scan a QR code or paste a bunker URL, approve the connection, and the app now uses your signer for signatures. Different implementations have quirks, with some using nostr+walletconnect:// URIs and some using bunker://. The underlying protocol is the same.

If something calls itself "Nostr Connect," it's probably NIP-46 compatible. Check the docs if you're unsure. With Signet, you should be able to connect.

Android app has been updated to version 1.1.1 ...

2026-01-02T05:25:33Z

Android app has been updated to version 1.1.1

https://zapstore.dev/apps/naddr1qvzqqqr7pvpzpk4yr0kmdpv3xcalgsrldp7tj7yuc4p76qjtka7z95kgfky02s2nqq2hgetrdqhxwet9dd6x7umgdyh8x6t8dejhgck8a3z

📦 Signet commit Added QR code to daemon for non-Docker ...

2026-01-02T05:10:13Z

📦 Signet commit

Added QR code to daemon for non-Docker instances which can be scanned via the Android app to set up a new server. Additionally, fixed several compilation issues that could cause issues when running signet-ui via pnpm.

7a0cf23
https://github.com/Letdown2491/signet/commit/7a0cf23fee3277d234af0cee42c4015db6ebfe6c