signet
Signet

Self-hosted NIP-46 remote signer

Public Key

npub1xmrca0288zwsnmduxzg3wd4m2a35a2qzn0sh68ckgm296ccv6qasvrwsfv

NIP-05 Address

Profile Code

nprofile1qqsrd3uwh4rn38gfak7rpyghx6a4wc6w4qpfhctarutyd4zavvxdqwcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsu890ey

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1xmrca0288zwsnmduxzg3wd4m2a35a2qzn0sh68ckgm296ccv6qasvrwsfv

Show more details

Last Notes

2026-05-11 17:26:32 GMT

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.

2026-05-08 16:15:50 GMT

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.

2026-05-01 15:59:29 GMT

What you can do with Signet:
Multi-key management lets you store and manage multiple Nostr identities in one place, including personal accounts, project accounts, and test accounts, all accessible through the same interface. The web dashboard lets you manage keys, review connection requests, and monitor activity through your browser, running locally on your network.
The Android app lets you approve signing requests from your phone, available on Zap.Store, and connects to your self-hosted Signet instance. CLI tools let you add keys and manage the daemon from the command line, allowing you to script it, automate it, and integrate it into your workflow.
Signet is NIP-46 compatible and works with any client that supports the remote signer protocol, including Amethyst, Damus, Coracle, and many others. Encrypted storage means keys are encrypted at rest with AES-256-GCM, and they only exist decrypted in memory when actively needed.

2026-04-20 16:13:23 GMT

Nostr can use proof of work to fight spam. NIP-13 defines how: an event includes a "nonce" tag with a target difficulty, and the event ID must have a certain number of leading zero bits, which requires computational effort to achieve.
Relays can require proof of work for posting. The harder the work, the more expensive it is to spam. Legitimate users do the work once; spammers have to do it for every message. This isn't mandatory and many relays don't require it, but it's a tool in the toolkit for relay operators dealing with spam problems. The difficulty is adjustable, easy enough for normal use, hard enough to deter bulk abuse. Economics of computation as defense.

2026-04-17 16:03:10 GMT

Bunker URLs are how apps connect to remote signers.
They look like this: bunker://pubkey?relay=wss://relay.example&secret=token
The pubkey identifies your signer. The relay is where the app and signer will exchange encrypted messages. The secret is a one-time token that proves you authorized this connection.
When you paste a bunker URL into an app, the app uses this information to send a connection request to your signer. You approve it, and now the app can request signatures through that relay.
The URL itself isn't sensitive after initial connection. The secret is single-use. But treat it like a password until you've completed the handshake.

2026-03-27 15:55:59 GMT

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.

2026-03-23 16:02:23 GMT

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.

2026-03-20 15:47:28 GMT

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.

2026-03-18 16:09:48 GMT

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.

2026-03-16 16:07:32 GMT

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.

2026-03-13 15:47:25 GMT

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.

2026-03-11 15:52:45 GMT

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.

2026-03-09 16:01:59 GMT

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.

2026-03-07 01:04:57 GMT

📦 Signet commit
Merge pull request #43 from vcavallo/install-ubuntu-24-fix
7c79aa0
https://github.com/Letdown2491/signet/commit/7c79aa0f334f661c709705435179b1ac9c2116d5

2026-03-07 01:04:56 GMT

📦 Signet commit
Remove hardcoded sqlite prebuild-install step
f44b8e1
https://github.com/Letdown2491/signet/commit/f44b8e1f32d5895ebc06d0ce7b6c92300d90748e

2026-03-06 15:41:01 GMT

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.

2026-03-04 15:47:40 GMT

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.

2026-03-02 15:45:04 GMT

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.

2026-02-27 15:40:03 GMT

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.

2026-02-25 16:07:33 GMT

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.

2026-02-23 15:50:48 GMT

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.

2026-02-20 15:39:57 GMT

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.

2026-02-18 15:56:09 GMT

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.

2026-02-16 15:44:27 GMT

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.

2026-02-13 15:46:55 GMT

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.

2026-02-11 16:05:36 GMT

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.

2026-02-09 15:59:45 GMT

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.

2026-02-06 15:43:23 GMT

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.

2026-02-04 15:48:18 GMT

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.

2026-02-02 15:40:13 GMT

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.

2026-02-01 06:36:53 GMT

📦 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

2026-01-30 15:38:58 GMT

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.

2026-01-28 15:37:18 GMT

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.

2026-01-26 15:33:27 GMT

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.

2026-01-23 15:30:10 GMT

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.

2026-01-21 15:36:53 GMT

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.

2026-01-21 04:02:11 GMT

📦 Signet commit
Implemented switch_relays method
e83318a
https://github.com/Letdown2491/signet/commit/e83318a77c539a4d21e71f6bff6144f48b892fe5

2026-01-19 15:30:27 GMT

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.

2026-01-18 01:02:06 GMT

📦 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

2026-01-17 18:16:02 GMT

📦 Signet commit
Implemented NIP-49 key encryption, plus additional UI tweaks and bugfixes.
c9b5c39
https://github.com/Letdown2491/signet/commit/c9b5c39491e16bbab72e8f7997860d187de2f5cb

2026-01-16 15:27:58 GMT

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.

2026-01-14 15:29:58 GMT

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.

2026-01-13 03:58:13 GMT

📦 Signet commit
Additional memory handling improvements in ACL cache and AdminCommandService
3863f21
https://github.com/Letdown2491/signet/commit/3863f215926c57c7d46ed4efaed24c7a412525e6

2026-01-12 15:30:06 GMT

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.

2026-01-12 06:22:21 GMT

📦 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

2026-01-12 01:00:44 GMT

📦 Signet commit
Add LogsPanel UI components for daemon logs
08e5cc6
https://github.com/Letdown2491/signet/commit/08e5cc6f14411b005fe334df3194316bd3b9a9bb

2026-01-12 01:00:44 GMT

📦 Signet commit
Fixed memory leak in AdminCommandService and SSE event handlers
479cd0a
https://github.com/Letdown2491/signet/commit/479cd0a4d186b175d5febbed8c9cf127d7e28aef

2026-01-11 21:10:12 GMT

📦 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

2026-01-09 18:18:27 GMT

📦 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

2026-01-09 15:28:12 GMT

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.

2026-01-08 00:57:25 GMT

📦 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

2026-01-07 15:29:37 GMT

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.

2026-01-06 03:58:08 GMT

📦 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

2026-01-05 15:28:19 GMT

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.

2026-01-03 06:18:01 GMT

📦 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

2026-01-02 21:09:08 GMT

📦 Signet commit
Fixed an issue that prevented the Android app from detecting version number.
ee0b3d1
https://github.com/Letdown2491/signet/commit/ee0b3d105cd8684fcc04f25f70fde69043ee36f7

2026-01-02 19:26:34 GMT

- reply

Android app has been updated to version 1.2.0
https://zapstore.dev/apps/naddr1qvzqqqr7pvpzpk4yr0kmdpv3xcalgsrldp7tj7yuc4p76qjtka7z95kgfky02s2nqq2hgetrdqhxwet9dd6x7umgdyh8x6t8dejhgck8a3z

2026-01-02 19:09:17 GMT

- reply

Android app has been updated to version 1.2.0
https://zapstore.dev/apps/naddr1qvzqqqr7pvpzpk4yr0kmdpv3xcalgsrldp7tj7yuc4p76qjtka7z95kgfky02s2nqq2hgetrdqhxwet9dd6x7umgdyh8x6t8dejhgck8a3z

2026-01-02 18:43:37 GMT

📦 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

2026-01-02 15:26:03 GMT

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.

2026-01-02 05:25:33 GMT

- reply

Android app has been updated to version 1.1.1
https://zapstore.dev/apps/naddr1qvzqqqr7pvpzpk4yr0kmdpv3xcalgsrldp7tj7yuc4p76qjtka7z95kgfky02s2nqq2hgetrdqhxwet9dd6x7umgdyh8x6t8dejhgck8a3z

2026-01-02 05:10:13 GMT

📦 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