Go to the top of your feed and tap on "All Follows" or whichever other feed option you have selected. Then scroll doen to the subject/hashtag you want to unfollow and tap on it. This should load a feed with just that subject and you should see an "Unfollow" button in the top right.
I still have them do on-chain and lightning separately, explaining that Lightning is like their checking account, or a small savings that you build up a bit before putting the funds into long-term savings (on-chain).
As for what wallet, generally stick with Phoenix for lightning and Nunchuk for on-chain. Nunchuk CAN be connected to your home node via Tor by pairing it with Orbot, but I feel like that's something they should do with their own node when they are ready.
Another thing to note is, I make sure to get them set up with a sizeable channel on Phoenix so they are not likely to run into surprise fees for needing increased liquidity.
That's going to depend on the client you are using. It is best to remember when asking questions about how to do something on Nostr that there are a wide variety of clients that all have different ways of doing the same thing. So, always include the client you are using when asking your question to get the best quality answers quickly.
Some clients allow you to long-press on the zap icon to change your default settings. Other clients will require you to navigate into your settings options and find the zap settings there.
Some popular clients:
Amethyst - Long press the zap icon.
Primal - Go to Settings>Zaps
Yakihonne - Go to Settings>Wallets and scroll down to the Default Zap Amount setting.
Coracle - Go to Settings>App Settings and Default Zap Amount will be right at the top.
Jumble - Go to Settings>Wallet and if you have a wallet connected you can change the default zap amount.
Nostrudel - Go to Settings>Lightning and you can set various zap amount options separated by commas.
As you can see, they are ALL slightly different. So which are you asking about?
Hashtags, used appropriately and in moderation are absolutely appropriate on Nostr and useful for discovery.
You can do anything you want on Nostr, and no one can stop you from using hashtags inappropriately, though. Hashtag spam is definitely an issue here. Little will get you muted faster than using hashtags to make your unrelated content more visible. So, keep that in mind when deciding to add them to your notes.
My general advice would be to only add a maximum of three or four highly relevant hashtags to your note. Bonus points if you can fit them inline within the context of your note, rather than placing them at the bottom or top of the note. If you have to choose top or bottom, choose the bottom of the note so people can read what you have to say first, and disregard the hashtags.
It's based on the pool. Any pools that payout via on-chain will have a payout threshold, because they want to minimize the amount of on-chain fees they have to pay.
The way to avoid these thresholds is to 1. have enough hashrate that you will meet or exceed the threshold more often, or 2. select a pool that will do payouts via Lightning, so you can receive payouts daily, even if they are very small amounts.
Two pools that will do payouts via Lightning are Braiins and OCEAN. Brains is, by far, easier to set up. However, they use FPPS, which means you will be paid less overall over time. OCEAN is much more difficult to set up, and requires the ability to receive via BOLT-12, and you may not agree with their stance on spam. However, you CAN choose to use a mining template that doesn't filter spam at all, if that is your conviction.
On Nostr everything is a note stored on relays, right?
That includes when you follow someone. The first time you follow someone, a note called a follow list gets created and stored to your relays. It is also referred to as a "kind 3" because different types of notes are differentiated by their kind number. The second time you follow someone, another new kind 3 is created, but it's not really separate from the first, because it has the original npub you followed on it plus the new one you just followed. Once a relay sees the new follow list with two npubs on it, it is supposed to delete the first one, so you only have one follow list at a time.
This makes it very easy for Nostr clients to display how many npubs you are following. They just need to look at your relays to find your most recent follow list and count the number of npubs listed on it. Done.
Now consider how a Nostr client like Amethyst would calculate how many people are following you. Remember, when someone follows you, the exact same thing happens as when you follow someone else. THEIR follow list gets updated to include your npub and saved to THEIR relays. So, if 200+ people have followed you, then a Nostr client has to try to find all of those follow lists, without knowing what relays they have been saved to, it just has to check as many relays as seems reasonable to the dev. But what if a follow list containing your npub is on a relay that the Nostr client didn't check, or it tried to check, but the relay was down or otherwise unreachable? Well, then its count will probably change every time you look at your follower count, because it is able to reach different relays each time.
Amethyst in particular updates the count in real time as it checks the relays, so when you first look at the number on your profile page, it will almost certainly be a ridiculously small number, even if you know you have more followers. Then, as it is able to reach more relays, the number will go up. Other Nostr clients may cache the information and update it periodically, so that you see a static number when you go to check it on your profile. Other Nostr clients recognize that follower counts are pretty meaningless, since anyone can spin up bots to follow them, so they don't show follower counts at all.
The reason Primal is able to "better" display your follower count than most other clients is because Primal does not work like most Nostr clients. Instead of reading directly from relays, Primal apps only read from Primal's centralized caching server, which in turn tries to aggregate all notes from all known relays. This means that instead of trying to look for follow lists from hundreds of relays in real time, Primal apps just have to check one server that the apps consider to have all the relevant information. That doesn't necessarily mean that Primal's number is accurate though, even though it is more stable. There still may be relays out there that have follow lists with your npub on them that Primal's caching server isn't aggregating notes from. There are also a lot of decentralization and censorship resistance trade-offs that come with using a caching server, rather than reading from relays directly. So this doesn't necessarily make Primal better overall, just different.
There are several problems with this proposal, but let's start with the most practical ones.
First, how will anyone know who to pay? Every node would somehow need to announce what Bitcoin address they should be paid at, and there would need to be a way to verify that the address is associated with a legitimate and separate node, not just someone announcing an address into the network without actually running a node. This is not an issue with mining rewards because the proof is in the data itself. They found a valid hash, so they get paid, and they put in the block that they created exactly how they get paid. Nodes don't do any PoW, though, so there is no way to verify whether an announced address really belongs to a node operator, or just some dude who wants some easy passive sats.
What happens when new nodes come on the network? They will need to store all the same data as existing nodes, so shouldn't they be paid by those who put that data on the network, too? Or should they only be paid for data that is added after they joined? If the latter is the case, then they are storing a lot of previous data that they aren't compensated for, but others were. What is their incentive to store that data?
The economics here is ridiculous. There are currently somewhere between 45,000–50,000 Bitcoin nodes. That number is not exact because it can't be. We don't know how many are running behind Tor or in other private networks, so the best we can do is estimate. Refer back to the first main issue with your proposal above. But let's just spitball some numbers here. If the proposal was something like 1 sat per KB per node, then a 1 KB piece of arbitrary data would cost 45k-50k sats with the current node count, plus the transaction fees for sending each of those transactions. Assuming this would be done using 1 input and 45,000 outputs on the low end, and best possible case scenario of 1 sat/vbyte transaction fee, the cost would be somewhere around 1,400,000 sats for the transaction fee alone, even with the lower estimate on how many nodes there are on the network. And node count would almost certainly go up, since this would be a direct financial incentive to run a node.
Things get more ridiculous from there, because 1 sat UTXOs are dust and unspendable. For a UTXO to be spendable, even in a low fee environment, it needs to exceed 546 sats, and practically, it needs to be more than 20k sats to be worth moving on-chain. And you HAVE to do this on-chain, because there is no way for Bitcoin to verify anything that takes place off-chain. If the node runners are paid via lightning, for instance, how will miners who select the transactions they put into a block know whether a particular transaction with arbitrary data included has paid the nodes to store that data or not? This means that even in the best-case scenario, each node must be paid a minimum of 546 sats for it to be above the dust limit, raising the cost to put arbitrary data on chain to a minimum of 24,570,000 sats for the 45,000 node runners to each get 546 sats, plus 1,400,000 in transaction fees, plus the transaction fee for the amount of data they are including in the transaction...
The final practical issue I will address is the fact that there is no way to prevent miners from including transactions that don't pay nodes a single sat. This is part of the basic game-theory that Bitcoin is built on. Miners select what transactions they will include in a block based on their own priorities, and since there are enough miners with different priorities, most transactions will eventually find their way into a block. Most miners operate on economic incentives, selecting the transactions that will result in them receiving the most fee income, but not always. If someone who really wants to put data onto the blockchain includes a high enough fee to the miners, without any payment to nodes whatsoever, some miner WILL pick up that transaction and include it in a block. The nodes could reject that block, but this would require a concrete consensus rule as the basis for doing so. A node couldn't just reject it because it contained a transaction with arbitrary data that did not also include a payment to the node's Bitcoin address to store that data. This would result in the nodes falling out of consensus with one another whenever there was a transaction that didn't pay absolutely every node on the network. But it couldn't be as simple as rejecting any block containing a transaction with arbitrary data that didn't pay any nodes, either. Otherwise the system could be too easily gamed, paying only one node, but all nodes then need to store the transaction forever. So it would need to be set to some standard of at least 90% of nodes. This would require each node to store a database of nodes and their Bitcoin addresses, so they could verify that the correct threshold had been paid, and this would become a new attack vector for breaking Bitcoin's consensus.
So, with all of the above practical issues, plus almost certainly a host of technical issues that would be above my head, and the social issue that such a change would be incredibly controversial, I think I can confidently say this idea is dead in the water.
I believe nostrplebs.com still offers this with their NIP-05 addresses. It would use a human-readable handle @nostrplebs.com rather than the user's npub, though.
The tough part is being able to go the other direction, so you can send a Nostr DM and it would convert it to an outgoing email. I am not aware of any services that allow both directions.
I am assuming that "free for anyone to use" is what you meant by permissionless. They are each centralized and moderated services. The only way for a blossom server to be truly permissionless is for the user to run their own.
Pretty sure both Primal's and Nostr.Build's blossom servers allow free uploads of up to 100MB.
Self-hosted and frictionless are not compatible terms, particularly in Lightning.
The most user-friendly is probably Alby Hub, by far, which is what I use on my Start9. However, you still have all of the same friction points of every self-hosted lightning node that come with having to manage your own channels, their liquidity, choosing quality channel partners, etc.
And then your Tor connection goes on the fritz, so half your channels are offline until you can get it back up, hoping your channel partner didn't force-close on you.
The constant cry is that we need to make this more straightforward for normies so they can self-host their own lightning infrastructure. Sorry, but that's not possible. Some of these things can be automated, for sure, but that just introduces a different set of friction points when the normie gets a much larger than expected fee, because they had no idea what inbound liquidity is, let alone that they ran out of it.
Most of the popular ecash wallets, such as minibits, provide a lightning address, and you use their mint by default. I believe any sats sent to that lightning address from outside of their mint would be converted to ecash from their mint, even if you have added other mints in the wallet.
The same would apply to lightning addresses from other mints, like cashu.me or npub.cash. Ecash sent to the lightning address from a different mint would first be melted and sent via lightning, and then minted as ecash from the mint that provided the lightning address. Ecash from the same mint that provided the lightning address would simply be sent as ecash from within the mint, though.
Sounds superfluous. Ecash wallets send via lightning when the user is not in the same mint already, and typically can detect from the lightning address if they are in the same mint to send as ecash instead.
Ideally, users should not have to figure out whether they should send a transaction as lightning, ecash, liquid, or any other payment rail. Lightning should be the interoperability layer that is front facing, and everything else just happens in the background without the user needing to even know what is going on.
Amethyst has auto-translate.
100% agree. Users should have some indication that the event will be protected, and ideally a way to select whether or not they want the event to be protected when they write to a single relay.
The protected tag is a relatively new feature that clients may have slowly been adding. I think it was originally thought up for the sake of lockbox and zapbox relays, so that there could be kind 1 and other standard note types that could be published to a specific relay that only a select group could read from. This would be more private than publishing to public relays that anyone can read from, but less private than encrypting the content.
My guess is that if the client has a feature to specify a particular relay to post to, rather than posting to your outbox relays like normal, it probably adds that tag, assuming that you ONLY want the note to exist on that relay. Generally a safe assumption, except in this case.
Whatever client you are using is adding the "-" tag to the note to indicate that it is a protected event, which should not be accepted as a rebroadcast.
Tollgate is a different product entirely, since it is the user paying the wifi provider directly. There's no reason someone couldn't create something similar to what you described, where the cell phone company pays the wifi provider in Bitcoin whenever their customers use the wifi, though.
The token used is arbitrary. They could have used Bitcoin for this if they had been inclined. Using Helium instead was a development choice that had nothing to do with its "usefulness."
Genders: I thought Amethyst already had the ability to add pronouns to your profile. Or were you talking about something else?
Country or City Feeds: Amethyst already has "Around Me." No one uses it.
Marketplace Improvements: That's generic. What specifically would you like to see improved about the marketplace?
Not quite what I am looking for. The one they have in CashApp is great for finding places that already have it turned on to accept Bitcoin, but I want to be able to find the ones that HAVEN'T turned it on yet, too.
Ah, yes. It does seem quite finicky. And now I notice that it seems to be communicating with Amber via my phone's clipboard. Not ideal.
Replying to you now from snort.social in Brave mobile browser using NIP-55 signing. No NIP-46 bunker string exchanged whatsoever.
That order of priority changes drastically if you are building a native Android app, though. Then you'd better have NIP-55 working out the gate or go home. Add NIP-46 when you can get around to it, and no need to bother with NIP-07 since the app isn't operating in a browser.
Keychat is just one of many options for NIP-07 signing. Alby, nos2x, and a couple others are out there, as well. NIP-07 is the most universally adopted signing standard for all Nostr web apps.
If you are building a PWA, then order of priority would probably be NIP-07, then NIP-46, and finally NIP-55 since it is Android specific.
If you use Amber already, then I highly recommend pairing it with Keychat for all Nostr web apps. Keychat uses NIP-07 like a browser extension would, but when paired with Amber it uses NIP-55 to reach out to Amber to get the signature. Both NIP-07 and NIP-55 are very reliable, so I have never experienced an issue with signing in Keychat.
Meanwhile, NIP-46 is very spotty, and it is hard to determine why. It seems like it works ok if you can initially get logged in using it. The problem is that it can take several tries before you can successfully log in.
Apps that present you with a QR code to scan a connection string seem to work better than ones where you have to manually paste in the bunker string from your signer app, but that means you are using that client dev's preferred relay for passing messages back and forth between the client and the signer, rather than the relay you prefer to use.
It's almost as if the client only looks for the signed connection request for a very short time, and if it doesn't see it on the relay in time then login fails and you have to try again. Highly annoying.
NIP-46 login is hit and miss across all Nostr apps, honestly. That's why I have also stuck with NIP-07.
Folks on iOS don't have much choice, though. It's NIP-46 for everything there, or else just hand out your nsec to every app, like it's haloween candy.
nostr:nprofile1qqs2zqnq524z7zfdsh3vpwpwjh4vt7xxp6sec68y3xr3ndvve23ru0spzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszynhwden5te0dehhxarjw4jjucm0d5hsgheky9, I just tried logging into Longform.space using Amber via NIP-46 connection string and it didn't work for me either. There may be something wonky with how Longform._ is handling NIP-46 signing.
In that case, Keychat is still really good for web apps by itself, but you do have to trust it with your nsec on iOS.
You on Android or iOS?
If Android, then Amber + nostr:nprofile1qqsth7fr42fyvpjl3rzqclvm7cwves8l8l8lqedgevhlfnamvgyg78spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qnse3k is a really powerful combination for all Nostr web apps.
Gotcha. I use a browser extension for signing into web apps. NIP-07 signing is still more reliable than NIP-46.
I am still using Longform.space and enjoying it.
Indeed. This has always been the case for abstracting away from the underlying asset; it improves payment speed, reliability, optionality, etc.
The nice thing about eCash is that it makes these improvements over custodial Lightning while maintaining the same trust model.
The thing that drives me nuts is when people characterize the trust model of Cashu as fundamentally worse than the trust model of custodial Lightning. They're both IOUs that are only as good as the custodian is honest.
Perhaps the main issue is that there is such a low barrier to entry to run a mint that users may be more likely to come across some random mint that rugs them, whereas custodial Lightning is typically taken on by businesses trying to build a brand and reputation, so the rug-risk is naturally lower. However, the trust-model itself is exactly the same.
Even that can be mitigated with eCash by spreading your risk among multiple mints, so that if one rugs you, it's a minimal loss.
10k sats/year or 1000/month. I chose yearly.
I just logged into it to confirm the above was still the case.
At least, I don't see anywhere to add any of the above.
Also noticed that it still has my "Declaration of Independence" note at the very top of the home feed. I guess they haven't figured out how to filter notes from the feed with timestamps well into the future. 😂
I tried out Yakihonne, but its composition screen is missing a couple things.
1. Nowhere to add a title image. That is, unless it is just taking the first image you add into the body of the article as the title image?
2. Nowhere to add a short description of the article.
3. Nowhere to add tags, except the body of the article itself.