Coracle uses bitcoin-connect. I've noticed some squirreliness with alby lately since the release of Hub. I'll see if I can figure out what's going on. @-mention me next time 😉

noooo

The only way to watch it really

Birdemic is so good

Chad

I was thinking to authenticate further sessions, but you're right, you could do the email login every time, that's fairly familiar.

Cool, looks like we're done for this cycle

But I need a password on signup anyway in order to authenticate with the server. Having two passwords seems unnecessarily confusing. Otherwise I like the idea.

Try selling nostr to 100 people in your church and tell me how it goes

😅

There are other value propositions nostr offers than owning your key. For example, a community member being able to run your infrastructure (a relay for use with flotilla). That's a more familiar selling point, and since the key storage is done in a trusted context, the small possibility of the key being leaked to the community admin can be overlooked. I'm looking at this specifically in terms of a group of people who are highly interested in one particular nostr application, and completely unaware of nostr as a whole. Even if they have to burn their key, it's an improvement because they learn what keys are, and that nostr exists.

Why a salted hash? And I don't see how the user can reset their password if the ncryptsec can't be rotated (unless that's done client side as part of the reset flow)?

That's a good call, encrypting an nsec is a very different thing. Hmmmm

nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpz9mhxue69uhkummnw3ezuamfdejj7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qyd8wumn8ghj7un9d3shjtnndp5hgen0wf3k2tn0dejj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qpqxdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wsej04v8 nostr:nprofile1qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcpz4mhxue69uhkg6t5w3hjuur4vghhyetvv9usqgrect9wz9829z5cre64nd870p22gu6jr2xj9fnth2ul5fywhqs07cseqye4

Thinking about email/password login further, here's a different approach:

Instead of encrypting at rest using a server key, what if the server never saw the key at all? Instead, the user would simply authenticate with the server, and retrieve an ncryptsec.

To avoid using the same password for the ncryptsec and the server authentication (since that would allow the server to decrypt the ncryptsec), the client could instead send the hash of the user's password to the server. (This would allow the user to avoid remembering two different passwords).

This would put key storage back on the client which comes with its own attendant risks, and benefits.

Is this better or worse than my other design?

nostr:nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzemhxue69uhkzat5dqhxummnw3erztnrdakj7qgnwaehxw309a3kcdpww3hxj7pwv3jhvtcqypavl24zxkmw0m8mateuucp763v4rlnmwewmysc33xx3qejhrv38xy3ndwu

That's true. But I think it's a well enough understood problem that it is the user's responsibility at this point. Are there user-friendly ways of ensuring high-entropy passwords though? The "at least one number" policies are both obnoxious and ineffective.

> Introducing friction reduces lock-in

Ironically, because normally it's the opposite. The single-app approach widens the top of the funnel (onboarding to flotilla) while narrowing the middle of the funnel (onboarding to other nostr apps). Depending on the relative sizes of those bottlenecks, this can be a win or a loss.

Introducing friction reduces lock-in. I want to encourage people to take custody of their keys. Not being able to sign in to the rest of nostr (especially when flotilla constantly links out to coracle) might be able to accomplish that.

See NIP 49

> So basically when I "log in" your client will generate local keypair and pass it's pubkey into your bunker and it will accept it if the password is right and hopefully will only give permissions that your client uses - so if local keypair leaks at least hacker won't sign kinds other than ones flotilla uses. Is that sort of correct?

The key is generated by and stored on the server, it never exists on the client. Other than the login flow, it's a normal NIP 46 nostrconnect flow. Probably a good idea to build permissions into the bunker, right now it signs anything.

> Why not send the ncryptsec immediately after signup to make sure user has the copy even if flotilla goes down?

Just UX friction, I don't want users to have to think about keys at all when they're getting started. Maybe I could do this after a week or something? Not sure.

> Do you store keys as ncryptsec and if server is restarted all users have to re-login and key is only decrypted if user supplies the password? This would sound better than storing all nsecs encrypted with a single server-side key, right?

I considered this, and might still do it. It would definitely improve security. Building a re-authorization flow would also allow me to expire bunker sessions instead of let them live in perpetuity.

> We could also standardize the API of your bunker so that nostr-login could work with your bunker as a replacement for localstorage key flow.

Good idea, do you think we should shove it into nip46 or just let it be a separate thing?

I wouldn't send via DM, but I do want seamless multi-device login for flotilla, which reliance on an existing session makes difficult

Burrow requires passwords to be at least 12 characters. Sending via email is a form of 2FA, since you need access to the password, and to the email account. That is at the expense of exposing the key to email servers, which you're right, isn't ideal.

Definitely a trade off, but I think it depends: nostr:nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqy88wumn8ghj7mn0wvhxcmmv9uq3camnwvaz7tmgdajxccn0vshxxmmjv93kcefww3hk7mrn9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhnyvtfv3jkzuewdehhxarjxyhxxmmd9uq3jamnwvaz7tmzwgh8qatjwpkx2un9d3shjtnrdakj7qpq8hhr9lmvgsf8ttd32hmxph2am7canlmjehy9fn809dahulvjuv0s6puhgl

Good points. I think you're right that it strongly depends on the application. Only apps that could be considered platforms in their own right (e.g. flotilla, primal) should probably do this, since the exploratory dimension isn't part of that app's value prop (even if they are a bridge to the wider network). Maybe this could be solved by making the original app a bunker? "Log in with flotilla". But this would probably only increase the lock-in to the original bunker, which is the opposite of my goal.

C'mon, roast me

nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpydmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef08ankcmmzv9kr6ctvdsq3yamnwvaz7tmxd9shg6npvchxxmmd9uqzq7k0423rtdh8ana74u7wvqldgk23leahvhdjgvgcnrgsvet3kgnny27dmq

no

You deserve a break, then BACK TO THE PUSHUP MILL

Far better than laser eyes

I wish I was that productive. Maybe if I count all the ones I delete over the course of a day.

So nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hszxthwden5te0dehhxarj9e3x7mn8vfhkueewvdhk6tcpr9mhxue69uhkummnw3ezucnfw33k76twwehzu6t09uqzqczwjmsfnym2zpyg89vtqs95weewpuzgex9v0yln0llycusz084jrueux2 are young to stop doing pushups now? Or just do 1000/day til 1000k

Try coracle.social. On the feeds page you can customize the feed to filter down to certain authors and people mentioned. Below is an example for conversations between me and fiatjaf.

So why are you so bent out of shape about it? Is there no reasonable motive for doing what fiatjaf is doing that doesn't depend on him acting in bad faith?

Codebuff is the first AI-assisted coding tool I've found so far that _might_ be worth using. But I'm stingy, so please help me get more free credits by using my referral link: https://codebuff.com/referrals/ref-3fcc22f4-10f9-419f-a0e9-e9d7b4368e21

I'm going to have to side with BS on this one

Is that all I am to you Vitor 😂

Just looked at their website and felt instantly queasy

They're making a competitor: https://polycentric.io/

Did the conventions for DVMs change overnight or something? All the content discovery DVMs are ignoring my job requests, so the e-tag filters I'm sending no longer work. However, if I p-tag the DVM I get plenty of stuff back. This seems to have broken nostrudel as well as coracle, but noogle works fine. This is sort of bizarre, if we want pubkey-based feeds then... just follow a pubkey.

What am I missing? nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgnwaehxw309ac82unsd3jhqct89ejhxtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0xy6rqtnxxaazu6t09uqzp75cf0tahv5z7plpdeaws7ex52nmnwgtwfr2g3m37r844evqrr6j2543uu nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3e82efwvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz8rhwden5te0wdshgetvd35hgefwdpa8yep3xsujucm0d5hsqgpxdq27pjfppharynrvhg6h8v2taeya5ssf49zkl9yyu5gxe4qg55la0jnz nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzpmhxue69uhkummnw3ezumt0d5hszxmhwden5te0wfjkccte9ehx7um5wfcxcetzwvhxxmmd9uqzpxdm2kgujytxqruy2yrax8umt83003lqng0lsqhgfuw58kj40jnywhdkjg

I'm not sure that would ever happen, since if they have a mobile signer they will choose nip 55 right? Which I want to encourage, so friction here seems good.

Eh, nips are for documenting common practices. If clients want to let users virtue signal, it's good to agree on how to do it

That's because there's nothing there, click on the menu items on the left (or in the menu on mobile)

PR is coming soon, I'll mention you when it arrives

It's a perfect way to save face in any mishap

lol this was not intended to be sent

Not a good time, but "errare humanum est"

Keys are simple, external 3rd party dependencies aren't (and, as you note, may not be any more secure). It's all about ease of use for non-technical users. But the days of nsec login are numbered, we just need really solid flows for secure custody. nsec.app comes close.

Normalizing using many keys for different use cases might be an improvement as well.

**Security Update**

I've got some bad news for you guys. This morning, as I was adding error handling to flotilla, I discovered that Coracle has been sending user session objects to bugsnag when reporting errors.

Who is affected: Users who triggered an error in Coracle while signed in with their private key, since December 5th 2023.

What I've done:

- I immediately released a new version of Coracle, both to web and to zap.store

- I have deleted the affected apks from my releases

- I have deleted all my error data from bugsnag

- I have deleted my bugsnag project and rotated my api key, so lingering error reports will be dropped

- I have audited my code for use of the session object to ensure nothing else like this is happening

What you should do:

- If you're logged in with your private key, log out

- Hard refresh the page to ensure you have the latest version of Coracle

The bottom line is that if you signed in to Coracle with your private key, it has been shared with me and with bugsnag. In practical terms, your keys should still be secure, since they were sent over TLS, and have been deleted. But there is no guarantee I can offer that they are in fact gone.

I take my users' privacy seriously. My error reporting implementation doesn't record user IPs, it redacts identifying data, and it allows users to opt-out. I also warn the user when they attempt to enter an nsec into a text field. In this case, I simply screwed up, and I sincerely apologize. Reply to this note if you have any questions.