Yeah, I got to thinking about this, when I built the gitcitadel.com login, with Npub, browser extension, Amber, and Bunker methods in it.

There are higher and lower-levels of permissions, dependent upon use case:

lurking: no permissions, just build a non-crappy client and default to a good relay

customized settings: npubread-only

casual interactions: anon logins

publishing notes under your own npub or using a write-protected relay: signer

Before performing any action, we should only ever be checking that they have the minimum level of permissions required for that action.

Make sure that someone who is lurking can zap or send emoji. Make sure someone logged in with npub can use their favorite relays and filter according to their own lists. Etc.

Until now, everyone has been doing this backward, sometimes even requiring "logging in with nsec" to see ANYTHING. So, the debate has all been about frontloading settings and sending invites, but this is actually a Nostr antipattern. You don't need to send someone an invite, for them to see what you see. Just send them your npub and tell them to login with that. Then we could have a button, "Create a new npub, with settings just like this one or define new settings." and they could click it and be done.

Or just send them a link to the website because it's a motherfucking website and you can just go there and do stuff, off the bat.

Reply to this note

Please Login to reply.

Discussion

I'm probably thinking this way because we're aiming at B2B and therefore aren't trying to make money off of the website itself or selling user data or forcing everyone to only use our relays.

If Alexandria were running on a university VPN, for instance, everyone would be logged into the server, already, and the relay could be local or etc. How annoying would it be to have to sign sign sign sign sign? You're already authorized to see this stuff and write to the relay, by being on the network.

A user could even create a custom profile for throwaway npubs to use the same username consistently without having to manage keys or anything like that.

We're all used to creating accounts for everything, so that surely influences our thinking.

Could also do a NIP-05 login, akin to the npub. Then they don't have to remember anything complicated.

Like, you could be NIP-05 logged-in, and then use anon npubs to sign.

The verification with NIP-05 wouldn't work on a throwaway npub. That would be just like setting up throwaway profiles with the same username.

I meant, to login as yourself, but read-only. Then you don't need to copy-paste your npub, you can type in laeserin@...

Oh yeah that would work for read-only.

The client would need to find the profile with that NIP-05 address, then it could use that npub to construct the user's view.

Another thing you could do is pay-to-play.

Our https://theforest.nostr1.com relay accepts all zap events, as those can be spammy, but so what. We can just let anyone zap and limit display of the zaps to a minimum sat amount _or_ write-access to the relay. You have to be whitelisted or pay at least 100 sats, for instance.

But, we can then allow them to include a message in the zap event (like Nostrudel does), and display that message in the feed, as a reply with a ⚡ icon or something (nostr:npub1636uujeewag8zv8593lcvdrwlymgqre6uax4anuq3y5qehqey05sl8qpl4 ?)

So, you can pay 100 sats to the pubkey, to have your comments show up, in our app.

And you can use anon zaps instead of private ones. Get away from encryption.

If you don't pay at least 100 sats, then just the money amount gets listed, not the comment.

This solves for advertising, as well. To advertise on Alexandria, you have to pay n amount to the npub who owns the thread.

Each npub could also set a minimum amount, all the way down to 0 sats, or a maximum amount, all the way up to 100k sats.

That's the cost of having your ⚡messages show up in their thread, for the general public. Anyone who is not logged in, can only send zap messages. Anyone who is logged in, can do either, anon or not anon.

Those are like sponsored messages, but for any npub, and the money goes straight to the author of the event being zapped.

What do you think nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q ?

Communikeys (and the apps built on them) have the advantage that:

1) they have a global state (and don't need to know who you are for reading + conditional display of replies, etc...). Spam is defined by the Community.

2) they can define their publishing conditions (price list) for each content type. So if the price for publishing an Article is ⚡ 100, they don't need to know anything about you to accept that publication.

That said, there are huge benefits to signing publications with your nsec.

To me, a good daily driver = your signer

Zapchat is (becoming) such a daily driver. (although you can browse in it without adding any profile)

Zapstore, on the other hand, is an app where "adding a profile" or "spinning up an nsec in the app" probably makes less sense. It can just display the app releases of some default communities, lets you select other ones. By adding profiles (i.e. getting npub info via Android Signer, like Zapchat or Amber) the UX will still be better though. And I don't see anything wrong with that. For publishing app releases, zaps, etc... you need a signer connected. And on Android and Desktop (not web), there is very little issues with that.

Yeah, it's highly use-case dependent. Is it my daily-driver or favorite community app, setup with my favorite relays? Sign away.

Am I just exploring it, is the repo owner bit dodgy/unknown or is it closed-source? No sign.

Do I only use it, occasionally? Read-only login and I interact over my daily driver's generic event search (find an event and hit *reply*, *zap* or *react*).

And so on. But the levels only work if the app takes the different states into consideration in the design, and tries to stick to the lowest state that is practical, with an offer to "upgrade" to a higher state, during a specific action.

They should always be upgrading _for some specific reason_.

Exactly

I can't wait to show you what I did with the wiki disambiguation page. 😁

You've created a feature monster. All your fault. I was old and needed the zaps.

I don’t know if it’s possible to thread comments that are all zaps and wallets have their own rules about content length and such.

But design wise, it’s possible to go multiple ways with this. Even so far as to allow a publisher to include a min amount in the index tags and have it honored by the client.

Ooooh, yeah. Custom zap-message amounts, by client, npub, or event. Damn.

And the client can have an option, for you to share your zaps with the devs.

Well, zaps have an e tag, so they can be replies, otherwise, they default to the kind 0 replies.