Bullish Bulletin
Bullish Bulletin is not a Nostr social client and not a wallet. It is a small public message board where a Lightning payment turns into a visible note, sheet or temporary takeover message, which makes it useful as a concrete NWC and Bitcoin Connect case study.
What Bullish Bulletin really is
Bullish Bulletin is a tiny paid public-message board. The live app is simple: a visitor presses the plus button, chooses a note format, types a short message and pays with Lightning. The visible options on the current page are orange post-it for 100 sats, purple post-it for 101 sats, 8.5x11 for 1000 sats and send a message for 10000 sats. The same page describes the project as a place to share thoughts while supporting The Bullish Bitcoiner and currently reports version 1.0.3.
That product definition matters because Bullish Bulletin can sound larger than it is if you only see it in an ecosystem map. It is not a general Nostr client, not a private messenger, not a marketplace and not a wallet. It is closer to a public cork board with a Lightning payment button attached. You pay for a bit of space, the app turns payment into visible content, and the board becomes the shared surface.
The Stacker News launch post fills in the intended flow. The builder described Bullish Bulletin as powered by NWC and said it lets people post a message on a post-it or sheet of paper, with examples such as job postings, ads or anything else someone wants to share. The same post says the user selects the note type, enters a message and pays the invoice displayed by Bitcoin Connect. That is the cleanest public explanation of the app's actual job.
Read it as a small Lightning interaction design, not as a fully mature publishing platform. Its value is that you can understand the whole thing in one pass. A payment is not an abstract donation or a hidden backend event. It visibly changes the board.
Why it belongs in Miscellaneous
Bullish Bulletin belongs in Miscellaneous because it sits between categories. It uses Lightning and NWC, but it is not a wallet interface. It has public messages, but it is not a social network. It can hold ads, notices or shoutouts, but it is not a commerce marketplace. It is a payment-powered micro-surface.
That label is useful for readers. Miscellaneous does not mean unimportant. It means the project should be judged by the specific thing it lets you do. Here the thing is paid public posting. The app is interesting because it shows how NWC can support small web experiences that do not need accounts, feeds, follows or a full protocol lecture before the user understands what happened.
It also prevents a common Nostr mistake: treating every NWC-enabled project as if it were a Nostr app in the social sense. In Bullish Bulletin, Nostr is mostly present through NWC and the ecosystem context. The reader does not appear to be managing a Nostr identity or posting a kind 1 note to relays. The user sees a board, a note type and a Lightning invoice.
That narrowness is a strength. Small projects like this are where the payment UX becomes easy to inspect. The hard questions are not buried under a feed or a hundred features. They are right there: who can post, what can be posted, what happens after payment, how long does it stay up, and what wallet permission was just granted?
The live product surface
The current live app has four paid choices. Orange Post-it costs 100 sats. Purple Post-it costs 101 sats. The 8.5x11 option costs 1000 sats. Send a message costs 10000 sats. The form shows character counters, including 21, 210 and 42 character limits across the visible entry states. Those limits are part of the product: this is short-message territory, not long-form publishing.
The visual metaphor is important. A post-it note is informal, temporary and public. A sheet of paper feels larger and more expensive. The send-a-message option is priced like a temporary takeover. In the v0.0.11 Stacker update, the builder said that after paying for send-a-message, the message takes over the bulletin for 21 minutes. That makes the feature feel closer to a tiny sponsored placement than a normal board note.
The same v0.0.11 update mentioned two other behaviors: hovering over or clicking a note can bring it to the front, and notes older than 21 days are removed. That retention detail is practical. It tells you this is not meant to be a permanent archive. It is a board where old paper eventually comes down.
Because this is a live web app, you should verify those details before paying. The page is already beyond the v0.0.11 update, and the current version text says 1.0.3. Prices, character limits, note behavior, retention and takeover duration can change faster than an article about the app. The correct habit is to read the current page first and treat older posts as context.
The NWC role
NWC is the reason Bullish Bulletin belongs in the Nostr ecosystem even though it is not a social Nostr client. Nostr Wallet Connect is an open protocol for connecting Lightning wallets and apps. The official NWC site describes a sustained interaction where an app can request payments through a Nostr relay after a connection is created. The Alby documentation frames NWC as a way for applications to interact with Lightning wallets through Nostr.
For Bullish Bulletin, the public evidence points to a backend or app-side NWC payment path rather than a user-facing Nostr identity flow. The Stacker launch post says the user pays an invoice displayed by Bitcoin Connect. The later v0.0.11 post includes code using an NWC client with an NWC connection secret to list incoming transactions over a 21-day window. That suggests the app watches paid invoices and uses the payment record to decide which notes should be visible.
That distinction matters for safety. A visitor may not be pasting an NWC string into Bullish Bulletin at all. The visitor may simply be paying a one-off invoice through Bitcoin Connect or a compatible wallet flow. The NWC connection could be held by the app or operator to create and inspect invoices. If the app ever asks you for a reusable wallet connection, that is a different risk profile from paying a single invoice.
The reader-facing test is simple: look at the wallet prompt. If you are only asked to pay a specific invoice for a specific amount, your risk is mostly the note price and public message content. If you are asked to authorize an app connection, inspect the permissions, spending limit, expiry and revocation path before approving. The same NWC protocol can support both tiny invoices and powerful recurring app access.
Bitcoin Connect in the flow
Bitcoin Connect is the piece that makes the payment prompt feel normal in a browser. The Bitcoin Connect project provides web components for connecting to Lightning wallets and exposing WebLN behavior without requiring the user to have a specific browser extension installed. That is why the launch post can say the invoice is displayed by Bitcoin Connect instead of telling users to manually copy a BOLT 11 string.
WebLN is the web-facing convention here. It gives web apps a standard way to ask a Lightning-capable provider to do actions such as send a payment or make an invoice. The Alby SDK documentation then connects this world back to NWC by exposing NWC through both direct NWC client calls and a WebLN-compatible provider. In plain language: a website can offer a familiar payment button while the wallet side may be powered by NWC behind the scenes.
For a tiny board, that abstraction is valuable. People who only want to post a 100-sat note should not need to learn every detail of relays, encrypted request events and wallet services. They should still be able to see the amount, approve or reject the payment, and know whether the post appeared.
The cost of abstraction is that users can miss what kind of relationship they just created. A one-time invoice is not the same as a persistent wallet connection. A browser wallet prompt is not the same as a server-side NWC secret. Bullish Bulletin is a good teaching case because the visible action is small enough that you can slow down and read the prompt carefully.
A public board is not a private chat
The most important privacy warning is almost embarrassingly basic: do not post anything on Bullish Bulletin that you would not want strangers to see. A bulletin board is public by design. Even if a note later expires, it can be seen, copied, indexed, archived or screenshotted while it is live.
That warning includes payment metadata. Your message and your payment may not be cryptographically linked for every observer, but the operator and payment stack can see more context than a random visitor. If you pay from a wallet that exposes a recognizable node, memo, lightning address or account trail, you should not treat the post as anonymous. Lightning payments are fast, not magical privacy blankets.
The Stacker post suggested uses like job postings and ads. That is fine, but those use cases invite personal or business information. A job ad can expose a contact route. An advertisement can expose a business identity. A joke can expose a person if it contains a name, phone number, address or location. The message box is short, but short text can still leak plenty.
A safer pattern is to post throwaway public text and use contact methods you already intend to publish. Do not put private keys, seed words, invoice secrets, email addresses, phone numbers, home addresses, private disputes, medical information or anything legally sensitive on a paid public board.
Moderation and paid spam
Paid public boards need moderation even when the payment amount is tiny. Charging 100 sats can reduce drive-by noise, but it does not stop spam, harassment, scams or illegal content. Some attackers are happy to pay small amounts if the board gives them visibility. The send-a-message takeover price is higher, but the same principle applies.
The live page's short description does not give a detailed moderation policy, refund policy or content-removal process. That does not mean the operator has none; it means a careful reader should not assume one. If you post something and later regret it, you may not have a self-service delete button. If someone posts abusive content, there may not be a public SLA for removal. If a paid note is removed for policy reasons, the refund expectation may be unclear.
This is where the physical cork-board metaphor helps and hurts. In a coffee shop, a staff member can pull down a bad flyer. On the web, the content can be copied before anyone sees it, and the operator has to decide what rules apply across jurisdictions. Paid placement also raises fairness questions: who gets priority when notes overlap, can old notes be pushed behind new ones, and can a paid takeover bury other paid posts?
If you are using Bullish Bulletin as a casual supporter, those questions may not stop you from paying 100 sats. If you are recommending it to a business, school, meet-up or venue, they matter. A public paid screen in a real place needs active moderation and a plan for abuse.
The coffee-shop idea
A reply under the launch post asked whether the app could run on a physical display for real-time bidding ads. The builder replied that the original idea included a touchscreen display in a coffee shop, where patrons could add a message to the board by paying a Lightning invoice. That is a useful clue for how to understand the project.
Bullish Bulletin is more compelling when imagined as local signage than as a global social network. A small cafe could let people buy birthday notes, jokes, meet-up announcements or sponsor messages. A Bitcoin event could run it on a screen near the entrance. A maker space could use it for paid public shoutouts. The point is not the note itself; it is the immediate loop between payment and display.
That physical use case also exposes the operational work. A venue needs content rules, staff controls, a way to hide bad messages, a refund stance, a screen-lock setup, browser refresh behavior, power and network reliability, and some accounting for who receives the sats. If the screen is unattended, moderation becomes harder. If the screen is in a family venue, content standards become stricter.
As a demo, Bullish Bulletin makes the idea feel obvious. As a venue product, it would need a fuller operator console. That gap is not a failure; it is the difference between a fun prototype and a product that a business can trust in front of customers.
Operator and code transparency
The public app identifies the supported creator as The Bullish Bitcoiner, and the Stacker posts are published by the same handle. There is also a separate bullishNWC web app from The Bullish Bitcoiner that describes itself as a Nostr Wallet Connect wallet for managing multiple connections. That helps place Bullish Bulletin inside a builder's broader NWC experimentation, but it does not make Bullish Bulletin's own backend transparent.
I did not find a public Bullish Bulletin source repository in the obvious GitHub search path during this pass. That matters because the app handles paid public content. Without source, you cannot independently inspect invoice creation, transaction matching, note storage, retention enforcement, moderation tools, payment failure handling or the send-a-message takeover logic. You can still use the app, but you are trusting the operator and the deployed code.
The v0.0.11 Stacker post is unusually helpful because it showed a code fragment using an NWC client and incoming transaction listing over a 21-day period. That tells readers more than most small demos do. It still is not a full audit. A snippet does not prove the currently deployed 1.0.3 app uses exactly that logic or handles edge cases safely.
The practical conclusion is modest. Bullish Bulletin is fine to inspect and test at tiny value. It should not be treated as audited infrastructure. If a project asks users to spend more than pocket-change sats on public placement, the next transparency step would be a public repository, terms, removal rules, refund rules and a current technical note explaining the payment and retention flow.
Payment failure modes
The happy path is easy: choose a note, type a message, pay the invoice and see the note appear. The unhappy paths are where small payment apps earn trust. An invoice can expire. A user can pay from a wallet that is slow to return control to the browser. A mobile browser can background the page. A Lightning payment can settle after the front end has stopped listening. A server can restart between invoice creation and note publication.
A public board adds content-specific failures. The message may be too long. The note may render behind another note. The user may accidentally close the tab before seeing confirmation. The operator may remove a note. The app may reach a display limit. A takeover message may be interrupted by another paid message or by a refresh. None of those failures need bad intent, but each can make a paid post feel broken.
When you test, use the smallest note first. Confirm that the wallet shows the amount you expect. Wait for settlement. Check whether the note appears, whether it is readable on desktop and mobile, and whether a refresh preserves it. If the note does not appear, treat the lost amount as the cost of testing unless the app gives a clear support path.
For developers, Bullish Bulletin is a neat reminder that payment confirmation is not the whole product. The app also needs idempotency, expiry handling, duplicate-payment behavior, content validation, storage durability, retention cleanup and user feedback. Small apps can skip some of that for experiments, but the skipped pieces are exactly where real users get confused.
Wallet permission hygiene
If Bullish Bulletin only presents a Lightning invoice through Bitcoin Connect, the safest path is to pay that invoice from a wallet you are comfortable using for tiny public experiments. You approve one amount, you see one wallet record, and you are done. That is the lowest-friction and lowest-permission model.
If the app, wallet or connector offers a reusable NWC connection, slow down. A NWC connection can include the wallet pubkey, relay, secret and allowed methods. Depending on the wallet service, it may support spending, invoice creation, transaction lookup, balance lookup or other methods. The Alby SDK docs show how direct NWC client calls can pay invoices, create invoices and list transactions. That is powerful, so the limit settings matter.
Use a dedicated test wallet or sub-wallet. Set a tiny budget. Prefer expiry. Name the connection clearly so you can revoke it later. Do not connect a main wallet with broad pay permissions to an experimental public-board app. Even if the app is honest, a leaked secret, bad browser storage pattern or confused permission prompt can create avoidable risk.
After testing, check your wallet's connected-apps screen. Revoke anything you do not need. If you only paid an invoice, there may be no connection to revoke, but checking is still a good habit. Small apps are a good place to practice the habits you will need before connecting larger apps.
Public content and payments change the incentives
Bullish Bulletin is more interesting than a donation button because the payer gets visible output. That changes the incentive. A donor pays because they want to support someone. A board poster pays because they want attention, expression or placement. The Lightning payment becomes both support and access control.
That can work beautifully at tiny scale. A 100-sat note is cheap enough to be playful but real enough to keep the board from being completely free spam. A 10000-sat takeover is expensive enough to feel intentional. The price ladder communicates the board's values without a long explanation.
It can also create pressure. If people pay for visibility, they may expect uptime, fairness and removal rules. If a message is rejected, they may expect a refund. If two users pay close together, they may expect ordering rules. If a venue uses it on a display, a paid message may become a customer-service issue. Payment turns a toy into a promise faster than builders expect.
Readers should appreciate the experiment without over-reading it. Bullish Bulletin shows a useful pattern: small paid expressions can be native to the web. The pattern becomes serious only when the operator defines the policy layer as clearly as the payment layer.
Nostr standards in the background
NIP-47 is the key standard for the NWC side. The NIP describes request and response events between a client and a wallet service, with methods such as pay_invoice and make_invoice supported in the wider NWC ecosystem. The NWC docs also list methods like get_info, get_balance, make_invoice, pay_invoice, lookup_invoice and list_transactions.
NIP-04 matters because the original NIP-47 flow uses encrypted direct-message style payloads. That does not mean Bullish Bulletin is a private messaging app. It means the wallet-app coordination can ride through Nostr relays with encrypted content between the parties that hold the right keys.
BOLT 11 matters because Lightning invoices are the object a user ultimately pays. WebLN's sendPayment method expects a BOLT 11 payment request. Bitcoin Connect can present that payment experience in the browser. The NWC and Alby SDK layers can create, pay or inspect invoices depending on which side of the app is using them.
Those standards are not visible to every user, and they do not need to be. But they are what separate Bullish Bulletin from a normal centralized payment widget. The app sits on open payment and wallet-connection conventions that other wallets and apps can share.
What to check before posting
Start with the live page. Confirm the current version, note prices, message limits and note behavior. Do not rely only on an ecosystem map or old screenshot. The current page is the thing you are paying.
Next, inspect the payment prompt. Confirm the amount in sats. Confirm whether you are paying one invoice or connecting a wallet. If you are connecting a wallet, check methods, limits and expiry. If the connector does not make that clear, use a tiny test wallet or do not proceed.
Then think about the message. Is it public? Could it identify you? Does it include a private contact route? Would you be comfortable with a screenshot of it circulating after the note expires? If the answer is no, rewrite it or skip the post.
After paying, verify the result. Did the board update? Did the wallet show the expected payment once? Did the message render legibly? If you used a reusable connection, revoke it when you are done. This is a small app, but the habit is the same one you should use with every wallet-connected website.
What developers can learn
Developers should study Bullish Bulletin because it keeps the payment loop visible. The app does not need a feed, a profile graph or a complex account model. It asks for payment, observes payment and changes public state. That is the smallest useful pattern for many Lightning-native web ideas.
The launch post's mention of Bitcoin Connect is a good design clue. Payment UX should be boring where possible. Users should see a recognizable wallet prompt, an amount, a confirmation and an outcome. The more experimental the product idea, the more normal the payment path should feel.
The v0.0.11 post's transaction-listing snippet is also instructive. If an app uses NWC to watch incoming payments, it needs a robust mapping from invoices to actions. It should know which payment bought which note, whether a payment was already processed, whether a note was moderated, and when retention cleanup should happen. Payment events are not enough; app state has to be durable.
Finally, developers should notice the policy gap. Tiny paid public apps need terms earlier than builders think. What content is banned? Who can remove it? Are removed notes refunded? What happens during outages? How long are messages stored? Are payment records kept after content expires? A playful product can answer those questions in plain language without becoming bureaucratic.
Where Bullish Bulletin is useful
Bullish Bulletin is useful for small public shoutouts, Bitcoin meet-ups, creator support experiments, demo booths and local venue concepts. It makes programmable Lightning feel tangible. You pay, the board changes, and everyone can understand the result.
It is less useful for private communication, durable advertising, regulated announcements, sensitive support messages or anything that needs guaranteed delivery. If a message matters legally, financially or personally, a paid public cork board is the wrong surface. Use a channel with authentication, support, retention guarantees and deletion controls.
For a reader exploring the NWC ecosystem, this is exactly the kind of project worth opening. It is small enough to inspect and weird enough to show why open wallet connections matter. NWC is not only for wallets talking to serious apps. It also lets people experiment with tiny paid interactions that would be too much trouble if every app had to integrate every wallet by hand.
Use it with the same spirit. Try it only with sats you are happy to spend, keep the message public and harmless, and treat the experience as a lesson in wallet-connected app design.
The practical close
Bullish Bulletin is charming because it is small. It takes the old cork-board idea and gives it a Bitcoin-native payment gate. A 100-sat post-it, a 1000-sat sheet and a higher-priced takeover are easy to understand without a protocol diagram. That is good product teaching.
The serious part is that even small public-payment apps need boundaries. The moment a user pays to publish content, the operator owes clarity about content rules, uptime expectations, removals, refunds, retention and wallet safety. Bullish Bulletin gives enough public context to understand the experiment, but not enough to treat it as audited infrastructure.
If you use it, keep the frame honest. Verify the current live page, pay only tiny amounts, post only public-safe text, inspect the payment prompt and clean up wallet permissions afterward. In that lane, Bullish Bulletin is a useful little NWC artifact: a paid public board that shows how Lightning can turn a simple web action into a visible shared moment.
Sources worth opening
Open the live app, its manifest, the Stacker News launch and v0.0.11 posts, the NWC ecosystem post, awesome-nwc, NWC docs, NIP-47, Bitcoin Connect, WebLN and the Alby SDK material. Those sources explain both the tiny product surface and the wallet/payment machinery behind it.
- Bullish Bulletin live app
- Bullish Bulletin web app manifest
- Bullish Bulletin app icon
- Introducing the Bullish Bulletin on Stacker News
- Bullish Bulletin v0.0.11 update
- Damus mirror of the NWC ecosystem post naming Bullish Bulletin
- getAlby awesome-nwc
- getAlby awesome-nwc raw README
- Nostr Wallet Connect official site
- NWC documentation
- NWC reference API overview
- NWC specification page
- NIP-47 Nostr Wallet Connect
- NIP-47 raw specification
- NIP-04 encrypted direct messages
- NIP-04 raw specification
- Bitcoin Connect repository
- Bitcoin Connect README
- Alby JS SDK repository
- Alby JS SDK README
- Alby guide: What is Nostr Wallet Connect?
- Alby guide: NWC JS SDK
- WebLN documentation
- WebLN sendPayment
- WebLN makeInvoice
- WebLN specification repository
- BOLT 11 payment encoding
- BOLT 11 raw specification
- Introducing Nostr Wallet Connect
- bullishNWC app by The Bullish Bitcoiner
- GambleAware
- NHS gambling addiction support
