Avatar
bumi
330fb1431ff9d8c250706bbcdc016d5495a3f744e047a408173e92ae7ee42dac
working on getalby.com - a browser extension with lightning and Nostr support
Replying to Avatar Tony

Are you looking into https://ghost.org/ integration, #[2]​ ? Many bitcoiners use ghost for blogging. I’m not a big fan of paywalls, but would be cool to see the way for my readers to zap with one click and especially log in with lightning. Is that something feasible any time soon?

I know there’s integration option for any website, where alby users see they can support or pay via LN as the extension lights up, but (1) not everyone has alby extension atm (sadly) and (2) buttons on the website are better reminders than extensions in the corner of the browser dashboard 😄

you can checkout: https://scribsat.com

I think we can improve the UX quite a bit here.

But if we want to move account creation fully into a Nostr client then we might limit self-hosting.

Or we would need to manage topup, channel management etc. also.

And even with custodial services we'd probably need some ToS that a Nostr client should not know about.

it would also bring support probably the the Nostr client as people might think they have the client's wallet.

Do you think an embedded browser potentially with predefined links for signup/connecting is that bad?

maybe let's first improve the connection UX to stay open?

How can we get Alby on to the whitelist of more paid relays to zap?

this depends on the used relay, right?

but zaps are public anyway.

do you know details about metadata leaks in LNC/commando/etc.?

those are the two competing schools that we see in nostr right now it seems. maybe implementations/adoption decide in the end?

cc #[4]​ can we bring in your thoughts. :)

(even though #[3]​ , I somewhat think it’s too early to discuss this publicly, this idea is still WIP)

not right now, but this is in development. wanna be an early tester for this? but I don't know exactly when it will be available.

"native apps" here is for the Tor connection.

but extensions never can talk to any native app only the special installed and configured ones.

"the native application must grant permission for the extension by including the ID in the "allowed_extensions" field of the app manifest."

this is typically used password manages for example.

technical details: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

important is the question where does it get encrypted or decrypted.

Is it software on your computer that only you control? (then only you can see it, good.) or is it software on a server run by somebody else. (then that other entity can also see it, bad.)

sadly sometimes this is a bit hard to see for the user - one good indication is if it is open source software running on your computer.

it is not stored at all, it is not even accessed (see the code)

but just because these extensions provide functionality (NIP07) to the websites you visit the extension "knows" which that you visited these websites.

What matters is that these extensions are client side applications and don't share data - (not like many browsers that save the browsing history to a google profile for example)

it's how browsers work. if you want the extension to provide functionality to the websites you visit (e.g. the nostr web clients) then the extension needs access to that. and thus also can read it.

You need to somewhat trust any software that you run on your computer. just by the fact that it runs on your computer.

IF you run the website yourself on your client then it's fine.

but ultimately the attack vector is much bigger having the keys compromised than having the keys in a local signing app on your computer that only signs.

If you want the extension to provide functionality to a website it has to have access to that website.

thus the extension and any such app should be open source and verifiable. This is how browser extensions work.

it is a bit like any software that you install and run on your computer.

Alby is a open source client side application. They keys are only in the software on your computer that displays messages.

end-to-end means it is encrypted from the sender to the receiver - but you need some software to decrypt it otherwise you'll never be able to read it. :)

this software must run only on your computer and nowhere else.

btw. changing the lightning address in the profile might invalidate old zaps. as clients check if the zaps are sent from that provider that is currently in the profile.