FAQ

It's me, StellarStoic! Unknown to the world because I always keep my distance from it. But you can find me on the protocols like Nostr and ...Nostr

or on the internets like SIGNAL and TELEGRAM

If you find something you believe is illegal, disturbing, or malicious, you can report the URL by emailing to report@snofl.com. Please provide as many details as possible about the URL in question in your email. I will do everything within my power to make the URL inaccessible if it is found to violate our policies.

The "Your Content" section is where you present your content to the end user. You can type freely and structure it as you like.

You can embed a Nostr note by pasting its reference with the nostr: prefix:

• nostr:nevent1… — the id and the relays it was seen on, which is what most clients hand you when you copy a note's link
• nostr:note1… — the bare id, still supported for older links

Both note1... and nevent1... work. nevent1 is what most clients give you when you copy a note's link, and it is the better choice here: it carries the relays the note was seen on, so the page fetches it from there instead of guessing. Profile references (npub, nprofile) are not embedded—sorry!

You can also include links to images or videos to display them in your custom page. Both Vimeo and YouTube links are supported and will generate thumbnails.

QR codes can be embedded using the qr: prefix, such as qr:somethingSomething. Some QR codes can include logos, which are used with specific prefixes:

• bitcoin:
• lightning:
• ecash:
• monero:

(If you think more should be added, let me know.)

Links starting with https:// will be formatted to open on click.

Note: Script tags are not supported in this section. If you attempt to post code, the URL will be invalid for the end user. If you must share code, take a screenshot and upload it as an image link instead.

ShowHistory is everything this browser posted, and nothing else — it is read out of this device's storage, not from a server or from the relays.

Each ID you have used gets its own card:

• a coloured dot and the random name it was given (weepy_bumph_13), with the number of notes posted as that ID beside it
• your public key, in full — click it to copy
• Reveal private key: asks first, shows the key for ten seconds with a countdown beside it, then hides it again
• a QR button that draws the key as a code, so you can import the ID into a signer or another Nostr client

Under the card, every note is a row: when it was posted, its kind, the text you wrote, and a Raw event line that opens the whole event as JSON if you want to inspect it.

At the bottom of the sheet, two actions:

• Download history — exports everything as a JSON file
• Delete all data — wipes every ID and note this browser holds, after two confirmations

Close the sheet with the ×, the Escape key, or a click outside it.

I am aware of the security risks of keeping private keys in a browser, but these are disposable IDs, and you should treat them as such.

When you post a response (a note), you receive feedback containing the event details. The note has been broadcasted to Nostr relays and is now part of Nostr forever.

You have several options to search for your note:

• Use src to look up similar content.
• Copy the event ID in the event details and search for it manually.
• Visit njump.me using the buttons below the event details.
• Copy the event ID with a button bellow the event details and search for it manually.

If you lost track of your posted note details, don't worry. All your posted notes are stored in the ShowHistory section, located in the footer below.

Yes — src is the discovery page. It looks up content on the Nostr relays that support NIP-50, and it searches by itself the moment it opens: type nothing and you still get what the relays hold, so the box is for narrowing, not for starting.

Several keywords at once work, and ANY / ALL decides whether a result has to match one of them or every one. Under each result there is a row of controls: hide the ones you do not want, block a publisher whose notes you never want to see again, and vote.

Voting is ▲ / ▼ with the counts inside the arrows. One npub counts once, changing your mind moves your vote instead of adding another, and pressing the arrow you already pressed withdraws it — the counts are read back off the relays, so they are the same for anybody who opens the page. Your own vote is tinted.

The badge in the top right is the key those votes are signed with: a random ID kept in your browser, held for 24 hours before it can be replaced, the same identity a custom page uses. Reading needs no identity at all.

A page you make with hashtags links to src, so people who find the tag find the page.

They are ordinary Nostr reactions (NIP-25, kind 7) tagged with that note's id and its author, signed by your own key — nothing about them belongs to snofl.

One npub counts once. The tally is kept per note as a map keyed by public key, so publishing the same + fifty times, or from five different apps, still reads as one upvote. NIP-25 says the latest reaction wins, so changing your mind moves your vote from one side to the other instead of counting on both. Pressing the arrow you already pressed withdraws it: that publishes a NIP-09 deletion (kind 5) naming your reaction, and relays that honour it stop serving the reaction — so it stops counting for everyone who loads the page afterwards, not only for you.

The numbers sit inside the arrows themselves, ▲ 5 ▼ 1, and tapping a number votes exactly the way the arrow does. Your own vote tints its count green or red.

What you see is the union of what the relays src searches returned, so a vote that only reached one relay shows once, and a relay that ignores a deletion keeps that vote alive on that relay. There is no server of ours in the middle to arbitrate.

No account, no email, no sign-up. src uses the same identity a custom page does: a random key kept in your browser with a name like quiet_lake_07, and it is held for 24 hours before it can be replaced (the ring around the badge shows how far through those 24 hours it is).

The badge in the top right shows the key your votes are signed with, and it is also where you replace it once the 24 hours are up. Reading and searching need no identity at all; only voting does, because an unsigned reaction is something a relay has no way to attribute.

The same key is used by the pages you open from snofl links, so a vote here and a note there carry the same name.

NTAG memory has been set with a careful reading of the NXP documentation papers

NTAG Memory Comparison

NTAG Type	Total Memory	User Memory	Max NDEF (Writable Data)	Max Text (Char.)	Max URL (Char.)	Use Case
NTAG 203	168 bytes	144 bytes	~137 bytes	137	135	Short URLs, automation
NTAG 213	180 bytes	144 bytes	~137 bytes	137	135	Basic vCards, small automation
NTAG 215	540 bytes	504 bytes	~492 bytes	492	490	Amiibo, longer vCards
NTAG 216	924 bytes	888 bytes	~868 bytes	868	866	Large records, WiFi configs
NTAG 413 DNA	416 bytes	404 bytes	~398 bytes	398	396	Secure URLs, anti-counterfeit
NTAG 424 DNA	928 bytes	916 bytes	~888 bytes	888	886	Secure vCards, payments

One button per thing a rendered page can actually show, and every one of them writes where your cursor is. Select a few words first and the button wraps them; press it with nothing selected and it inserts an example already selected, so you type straight over it. The name under each button says what it does, so nothing depends on hovering — which matters on a phone.

A page renders HTML, not Markdown. **bold** and # heading would stay as literal characters, so the Bold button writes <b>, Heading writes <h2>, and Table and Fold write a real <table> and <details>. The one Markdown form the page honours is [the words](https://address), which is exactly what Link writes.

What is there: bold, italic, underline, strike, highlight, small, two heading levels, bulleted and numbered lists, quote, inline code, preformatted, table, fold, horizontal rule, link, image, note reference, calendar event, the five QR prefixes and poll — 26 in all, in a row that scrolls sideways. Ctrl/Cmd + B, I and K do the same as the first three.

After each press the line under the strip tells you what it just added and what it cost: this text lives in the link, and the link has to fit a tag. Around a word, <b>…</b> is 16 bytes in the URL, <hr> is 14, and the table template is 182.

Yes — calendar events are NIP-52, kinds 31922 (whole days) and 31923 (a time), and a page draws one as a card with the title, the date, the place, the summary and optionally an image, instead of treating it as a note.

Press Calendar in the strip: it opens a short form — title, time or whole days, timezone, place, summary — publishes the event under your own identity and drops its reference into the content. If you already have a reference from somewhere else, that form's second button hands you the caret with nostr: ready. Both forms work:

• nostr:naddr1… — what clients hand you for a calendar event, because these events are addressable: the author can replace one, so its coordinate (kind + author + identifier) is the right handle rather than an id
• nostr:nevent1… — an event id with relay hints, still drawn as a card if the event turns out to be a calendar entry

Times are shown in the event's own timezone when it names one (start_tzid), otherwise in yours. A whole-day event's end date is exclusive in NIP-52, so "1 May to 4 May" is shown as 1–3 May, which is what the author meant.

The card also carries the three answers — Attending, Maybe, Declined. Pressing one publishes an RSVP (kind 31925) signed by your own key: an a tag naming the event's coordinate, a status, and a d that is the coordinate itself, so answering again replaces your previous answer instead of piling up. The counts beside each button are read back off the relays — newest answer per person, so nobody can be counted twice — and your own choice is tinted. Changing your mind moves the count rather than adding one. RSVP needs a Nostr ID on the page; without one the card says so instead of failing quietly. Adding an event to a calendar app from the page is not there yet — "open in njump" is the way out.

As you. The form in the maker signs with whatever identity you chose in the maker — a browser extension, a remote signer, or the anonymous key that lives in this browser — and publishes kind 31923 (a time) or 31922 (whole days) to the relays in the maker, or to the defaults when you have not set any. The status line under the form says how many relays took it, and when none did, it repeats what they said instead of failing quietly.

Because these events are addressable, the reference is a coordinate (kind + author + identifier), not an id: republish the same identifier and every page pointing at it shows the new details. That also means the event belongs to the identity that signed it — publish it anonymously and it stays with that anonymous key, so it is worth signing in first if the event matters.

Times are sent in unix seconds with start_tzid so a reader in another country sees their own clock time. For a whole-day event the form turns the last day you picked into an exclusive end date, which is what NIP-52 expects — pick one day and the card shows one day, not two.

Press Poll in the content toolbar for a small form: the question, two to six answers, and how many of them one person may give. Press Insert into the content and it is written into the page. You can also type it by hand:

[poll:Your question|First choice|Second choice]

Two to six options. [poll2:…] lets each person pick two instead of one — the digit is how many answers a person may give, and it is the form's "Each person may give" choice. Put the caret on a poll you already wrote and press Poll again to reopen it with its values.

The poll is not a room message: the declaration travels inside the link, so every reader sees the same question and nobody has to publish it first, and only the answers go to the room, using the same NIP-88 payloads, mining and counting the room already uses. Its id is derived from what the poll says, which means moving spaces or changing case cannot shift everybody's answers onto a different question.

On the finished page the card sits above the notes with the question, the options and the counts. A poll appears only when the link declares one — the maker is the only place a poll comes from, and a page without [poll:…] in its content shows no poll and no poll button at all.

Yes. One is where the visitor starts, the other is how long their note may be, and they were once mutually exclusive for no good reason — switching one off cleared the other.

There is one rule between them: the suggested message has to fit inside the limit. While you type, the limit row says where you stand — The suggested message is 44 characters, leaving 236 for the visitor — and turns amber when it no longer fits.

If it does not fit, no link is made at all and the reason is spelled out, rather than a link that would quietly change what you wrote once the visitor's box caps the text.

Both controls live in Visitor options, together with Public notes, because a suggested message only means something when a visitor may post at all: with Public notes off the message switch is unavailable rather than merely pointless.

Press Done in its top right corner, press Escape, or click the dimmed background. All three only close the editor — the content stays switched on, stays in the field and stays in the link.

That is worth stating because it was not true before: the editor's open state was the content switch, so the only way out also took p out of the link and the page you had just written stopped existing. Write in full view opens the editor again without touching anything.

Inserting from the button strip never takes the screen either: the editor opens on a real flip of the switch, not because a button enabled the field behind your back.

Not while the browser session lasts. The content, title, subtitle, suggested message, the three hashtags, the three relays and their switches are saved in sessionStorage as you type and restored when the page loads — switches first, so no value lands in a field that is still disabled, and the link is rebuilt with them. A reload never puts you back into the full-screen editor.

Close the browser and it is gone. That is deliberate: the draft never leaves your device, nothing is stored on the server, and it does not follow you to another computer.

Clear draft throws it away on purpose. The styling choices — avatar, font, background, Lightning address, encryption — are not part of the draft; those you pick per link.

The current font used on this website is loading....

You don't like the loading... font? Not a biggie! Click here to choose a new random one.

The security of the URL encryption on this platform relies on AES (Advanced Encryption Standard), specifically AES-256. This encryption standard is widely recognized as one of the most secure methods available today and is used globally to protect sensitive data, including government and financial information.

🔐 What Makes AES-256 Strong?

• Key Length: AES-256 uses a 256-bit encryption key, offering 2²⁵⁶ possible combinations. This is a number so large that even modern supercomputers would take billions of years to brute-force it.
• Cryptographic Strength: AES is a symmetric encryption algorithm, meaning the same key is used for encryption and decryption. This simplicity ensures high speed without compromising security.

Examples of Password Strength and Brute-Forcing

Password Length/Type	Time to Crack (Brute Force)
Weak (e.g., "12345")	Instantly
Moderate (e.g., "P@ssw0rd")	A few hours with modern hardware
Strong (e.g., "F&2zL!8x9wXy@#Tp")	Over 1 trillion years

Best Practices for Maximum Security

• Choose a password with a minimum of 12 characters, including uppercase, lowercase, numbers, and special symbols.
• Avoid common words, predictable phrases, or keyboard patterns.
• Store passwords in a secure password manager instead of relying on memory.

A Brief History of AES

AES was established as the encryption standard by the U.S. National Institute of Standards and Technology (NIST) in 2001. It replaced the older DES (Data Encryption Standard) due to advancements in computing power that made DES vulnerable. AES was selected through a global competition and is based on the Rijndael cipher, designed by cryptographers Joan Daemen and Vincent Rijmen.

Why Privacy Matters

Protecting sensitive information like URLs ensures that your personal data and activity remain private. Encryption plays a crucial role in safeguarding secure links and confidential content, providing peace of mind that unauthorized access is nearly impossible. However, centralized institutions have a poor reputation for securely storing personal data, highlighting the need for individuals to take control of their privacy. While encryption is a powerful tool, it’s only as strong as its weakest link—humans. Mistakes, phishing, and social engineering can compromise even the most robust security systems. Empowering users with knowledge and awareness is just as important as using strong encryption.

Always remember: The strength of encryption depends on the strength of your password, your opsec and people you share this password with!

Every link you shorten is kept on my server rather than on Nostr: the long address sits in a small database and the short code only redirects to it. The chck page reads that one row and tells you:

• how many times the short link has been opened,
• when it was last opened (UTC),
• the long address it points at,
• how old the short link is, and
• how long it has left before it is deleted.

You can reach it from the footer as chck, or straight from the QR window: right after you make a short link, Check this link's visits opens the page with the code already filled in.

Short links are kept for 2,100 days — a little under six years — and the page counts that down to the hour. If something had to be removed because of a report, the page says so instead, with the date, how many times it had been opened and the reason.

One thing worth knowing: those numbers are not private to you. Anyone who has the short code can open the same page and see the same count, the last visit and where it points — the lookup answers one code at a time, so nobody can walk the whole list. If the destination is something you would not want a stranger to read, do not shorten it.

You can't

Four controls, all optional, all in Visitor options:

• Public notes — off writes n=0 and the page offers only the encrypted room. On, a visitor may post a note anyone can find, with the hashtags you chose.
• Suggested message — m=, the text they start from.
• Visitor can edit it — off writes mr=1 and the field becomes read-only: still readable, still selectable, still posted, just not rewritable. The page says the author wrote it.
• Max characters — l=, between 1 and 5000, 280 if you say nothing.

They chain: no public notes means no suggested message, and no suggested message means no editability choice. Each one says so next to itself instead of just sitting there greyed out.

Watch the byte count above the buttons in the link panel — it reads Remaining bytes: … (Current bytes: …) for the tag you picked, green while it fits and red when it does not, and it updates as you type (on a phone too, where it sits in the pinned panel).

The content is usually the long part, and it is URL-encoded on top of that: every < and </> becomes %3C / %3E, three bytes each, and every space becomes %20. A table template on its own is 182 bytes.

In practice: drop whatever the page does not need, shorten the wording, skip a custom background or avatar if you can live without it, choose a bigger tag (NTAG213 → 215 → 216), or shorten the finished link with the built-in shortener — the long URL is stored on the server and you get a short one to write.