Replies (101)
Thanks for disclosing. Would this affect nostr browser extension logins through nos-2x or Spring Browser?
This is why we need to be vigilant with signing apps. Only give your nsec to a signing app, that way you never share it with anything else.
thanks 👍🙏
Were the keys ever stored (not just transmitted) in plain text on bugsnag, like could you login to that platform and see them?
Amber
it happens... truly it's the most nightmarish thing about being a programmer, how many people can get messed up by your mistake
good that it's found and fixed and move on and don't forget... we live in a world where many clearly bad things are said to be "ok" when they are not
I assume this is a good reason to always use signing extensions yes? That would avert issues like this, unless the extension itself was somehow compromised or had a bug, is that right?
Yep, remote signers and browser extensions are a great solution for this, and have been around for years now.
good on you for informing users of the breach. 🙏 not an easy choice. I think many devs would just cover it up.
I hope others that see this realize that this makes coracle more trustable and not less.. 🎇
1. I'm lucky to have always used nostr apps with key signing extensions on both phone and laptop.
2. I didn't know Coracle had an apk...
hodlbod
**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.
View quoted note →
Damn, too bad. That must really suck. Good luck and I hope you get this all figured out.
Serious question: Are signing apps considered standard best practice ATM?
Frankly, as long as I'm going to be pasting my nsec into any app - even if I know it's only ever going to be pasted into that one app - I'm still not going to trust that nsec with anything important.
It's a good thing he disclosed it. It definitely makes Coracle a bit more trustable in my mind knowing that even in the case of a mistake it will be disclosed.
Definitely reinforces the fact that you should never raw dog your private key into any application, no matter what. I don't really think most people do that nowadays, but its a good reminder.
hodlbod
**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.
View quoted note →
Thanks for the announcement.
Do you plan to deprecate raw nsec login in future versions? Signing extensions and remote signers are the security habits we should be encouraging users to adopt.
Thanks for letting us know. I appreciate your openness and disclosure. All good. 🫡
Do not enter your private key into a web app! Why are there Nostr apps that are doing this?
Second, a dependency supply chain attack could make even signer apps leak passwords.
hodlbod
**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.
View quoted note →
Perhaps it would make sense to post a list of signing extensions on the login page, and recommend that people use those rather than entering an nsec, or perhaps you already do that?
This is how bug should be handled--openly and honestly.
Kudos to you. 😃 We all make mistakes...we're not God, and while we try to be perfect...well...
And (frankly) at some point everyone on Nostr needs to understand their nsec is effectivley not private, as AI will be able to dox any of us (so long as you have enough posts to begin developing a "profile"). Sorry, but it's true...
In fact, I've been thinking that perhaps a good practice would be to abandon a profile (nsec) periodically and start over...thinking about how that might (or might not) help...
Regardless,
@ hodlbod you've gone up a few notches in my book.
Thanks for all you do, and for updating us.
Not necessarily...there's nothing that ensures remote signers and extensions don't have similar issues...
Using signing extensions and signing applications are paramount.
hodlbod
**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.
View quoted note →
Why have it even as an option?
Thanks for being honest, but holy shit.
The response we wish to see everywhere on the web, that we don't!
hodlbod
**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.
View quoted note →
based honesty. keep doing what you do hodlbod; we appreciate you. 🫂
Your last sentence is important--what you're really asking (or assuming) is that we can "trust" the code more in signing extensions (and frankly that may not be the case).
This is one of the weaknesses in the open source community. We all assume that because the code is available to all, it's "good".
But what really happens (in more cases that we might want to admit) is the only "audit" the code receives is from the original developer--I'd even dare to say that most projects out on git hub probably receive very little (if any) code review prior to being released.
Unfortunately I don't think you can get simpler than nsec login. It's also the easiest way to create an account. Anything more is very confusing for normal people. You either have server-side custody, a different browser app like nsec.app, or a new app on your phone, all of which can have the same problems. A key rotation scheme would be an improvement worth having, and educating users to reduce key exposure and not use their main key for storing ecash or secret communications or whatnot seems like the way forward in the short term at least.
Normalizing using many keys for different use cases might be an improvement as well.
the complexity of clients makes it more likely however
the point of isolating it in a simple, single purpose thing is to reduce the chances of there being a vulnerability
it's a point lost on many programmers these days, the reason why the Unix philosophy talks about small, single purpose, modular applications. Security is a big part of why, but a small part of the broader problem of bugs, which also cause other inconveniences
MY NSEC WILL NEVER LEAVE THE VAULT
GitHub
GitHub - VnUgE/NVault: A self-hosted, multi-user, nostr credential vault, with cross-browser NIP-07 extension
A self-hosted, multi-user, nostr credential vault, with cross-browser NIP-07 extension - VnUgE/NVault
Users using uBlock origin would likely have been protected by default, I know I am. You should always be using blocking tools such as script blocking extensions or DNS blocking to disallow apps from sending YOUR data to 3rd party servers. I encourage other developers to avoid even the slightest possibility that you could be responsible for compromising user's identities.
For web applications I think it's time to deprecate nsec login.
View quoted note →Requiring an extra signer app or extension is not much different from a service like Gmail requiring a two-factor authentication scheme when you create an account.
We should work to create a "pit of success" for users to fall into, and I'm concerned that raw nsec signing doesn't do that.
UX research and future development in the Nostr space could probably produce low-friction identity creation that guides users into creating an nsec and storing it securely in just a few clicks/taps. It's not an easy problem to solve, but could provide huge value to users.
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.
i think there should be more than one signer... and some thought needs to be put into how to do it on desktop with browsers
you can recommend people install nos2x or amber, and remove it from your web and desktop versions...
i agree with the principle of it... the more complex an app, the more likely it is to have a bug and if it's a security feature, potentially a vulnerability
people should also be wary not to make these signers into all singing all dancing omni-apps also
Yes, I guess I am hoping (!) that the code for a signing extension would be rigorously reviewed.. and even then, I am aware it could have a vulnerability (but any code could have that, so at some point we (esp us non-coders) have to *trust* the code 😅)
Agree...I use "browser isolation" for most of my surfing, where I use different browsers and different extensions for different purposes (e.g., I only sign into Google on Chrome, and I only surf using Chrome at websites that I'm ok with Google knowing about). I can envision doing something similar with Nostr...
Nostr is so new, we're still on the bleeding edge--things will evolve and get better...
Right now we're driving Nostr's "Model T" - transformational at the time, but quickly evolving as technology and development leaps ahead...
Just wait until we develop the twin-turbo V8 Nostr apps... 😃
Some fuck up was bound to happen with using nsecs to login
hodlbod
**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.
View quoted note →
Agreed. Unless you've diligently ensured your nsec has continuously remained isolated from the Internet (which might be nobody), it's prudent to operate as if your nsec has already been compromised.
Well, there's the rub...unless you go in and review the code yourself, you must end up trusting others...
And when someone like
@ hodlbod posts "hey, we have an issue" I automatically trust that developer even more.
What I *really* worry about is dishonest projects / developers, and you see it all the time. Someone releases an app on the Play Store that does something nefarious...happens more often that most realize.
And look at all the data breaches out there--those are code mistakes that ARE audited (heavily) and still they happen...
I am guessing two possibilities:
1. The friction to onboard new users would be pretty high as it currently stands, if they have to go and figure out using a key extension.
2. The developer, in this case @hodlbod, would need to trust that the signing extension options are excellent, and have been audited rigorously.
I can imagine that as a developer, if one knows one is acting in good faith, it might be easier to trust oneself and one’s intentions, than those of others?
Curious to hear thoughts, esp from developers
@ hodlbod @jb55 @Vitor Pamplona @miljan @Martti Malmi @Kieran @brugemanAgree...(in theory).
How many times to devs pull from a library of "trusted" code, only to find at some point in the future that "oops, we found a bug in library x"...
Often it's no one's fault--but it happens.
So modular applications / libraries come with potentially even a greater risk... 😃
I hear you. What do you see as the solution?
I don’t have one, though I do see it is probably a good idea to let new users know that this issue has not been solved, and that they need to be aware that there is a chance their nsec could be compromised.
Of course, that would cause friction too, but my approach with onboarding people to both #bitcoin and #nostr is to remind them that this is all a big experiment, and we are part of it, part of creating the potential for freedom, even as we move into a digital age.
So this is perfect--and what should happen.
We find a bug, and it's now opening up a great dialog on potential ways to improve Nostr and the log-in / account creation and maintenance processes.
"Making a mistake is a gift...you now get to fix it AND make things better!" 😃
Love this thread!!
Thank you for letting us know.🙏
Entering a private key into a web app is much less secure than a signer app or extension. However, a signer app still can have its issues, just less.
A few of the issues:
- Phishing attempts from similar looking domains.
- Hot loading code from a remote server, not signed releases from the maintainer.
- Encourages entering nsec somewhat carelessly into more than one web app. It could be entered into a clipboard, which as been another vector of attack.
- Users habits of this type of behavior from passwords on every other web app. Passwords can be reset via email resets, a private key can not be reset. It can thus not communicate the importance of it not leaking, and thus careless backups and storage.
None of that is good for non-technical users.
Honest devs should be Zapped! Thank you
yeah, the problem was relays
and the reason was complicated, ugly languages used to implement most of them, that make changes difficult to reason about
It's a good start, but ultimately a custodial honeypot. Self-hosted bunkers are much better, but hard for normies. Multisig could be a great way to solve this, I know it's been worked on some.
🫂
This is why I use nos2x :-)
Thank you for the disclosure. 👍 👍
Nsec login definitely doesn't make much sense, aside from "bunkers are high friction for now so Damus users should just paste nsec". This will improve as bunkers improve, I will share a significant step forward in this area next week.
Local nsec signup makes total sense - let users start asap but then let them export nsec to a bunker. Nostr-login widget has this option built-in, only works with nsec.app for now but will be proposed as NIP upgrade when we are confident it's good enough.
I remember someone proposed to unlock btc wallets with nsec nostr key.
Mmmm bad idea.
Thank you for the transparency & if anything else … a nice reminder that private keys need to be kept private.
Secondary question. Can ppl rotate their nsec? And generate new private public key to a Nostr account? #askNostr
I agree, nsec.app is the smoothest experience I've seen so far. Thinking about seeing if I can integrate it into the onboarding experience in Coracle, friction notwithstanding.
Respect for the full disclosure
Awesome! I'm sure there's a lot to improve there, please let me know if you have ideas or issues.
There's no standard way to do it, but lots of people have success with social key rotation. Just make a new key and tell your follows you've moved. I'm sure we'll eventually come up with something more streamlined.
start establishing the self hosted bunker paradigm now. its going to be necessary for the internet of the future
Pretty sure I've always used a browser extension. I was not able to use amber on the mobile app on android, so I never signed into it.
3rd party data holdings always seem to be a big security issue. Even if you're honest as a dev, they may not be. Many stories of 3rd party services being the cause of data leaks the past few years too.
can you ask bugsnag to ensure data is wiped and not softdeleted?
Ah man, that's shitty! But the way how you handling this is an example for other. I'm 100% sure you did not do this on purpose ;) It takes courages to be such open and honest about this.
It reminds me of this note too ;)
note1n2tksh06q93fqvj25xrumfavw2va3k9nyz5jsves2jawukj2fl9sgum268
youre a good man. 👍
Why not use a self-hosted error tracking system?
Imagine if we had institutional transparency like this.
View quoted note →Honestly it shows a lot about your character to voluntarily disclose this. Good on ya fren. 🫂
not your keys not your korn
Respect for the transparency, I have so much to learn here, keep building
That's an honest days work my guy
Sorry to hear that. Is there any way to check when one signed into corracke giving nsec?
I have no idea what Coracle is
Can’t know much about Nostr apps then
Thanks for the transparency! Keep up the hard work.
Might be my ignorance to the tech but I thought all signing was done on the front end and so signing in (with an extension for example) was just a client side session and that the nsec never got shared server side.
Thank you for letting us know. But I guess at this stage, almost everyone’s keys is compromised 😅 I don’t know if I ever logged in with my nsec, but there is a chance I did. I personally don’t believe anything gets deleted ever, so I’m going to guess all the data on bugsnag are still there.
Have you contacted bugsnag about this to make sure they “full format” your data, or will that cause even more attention?
Finally, I would suggest that nsec login to be not only discouraged, but not be possible. Like primal.
Thank you for being honest and open about this. I used Coracle so I'm using this as an opportunity to see what migrating to a new nsec is like.
Props for the disclosure. I used Coracle so I think now is a good opportunity to see what migrating to a new npub is like.
This is why I burned my doxed/ compromised key to start fresh with this one. Don't be afraid to start over. We are still early. It's easier to rebuild 600 follows now then 1000000 in 10 years.
hodlbod
**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.
View quoted note →
I used alby, but Is there a way to check if my key was compromised with my npub?
Cool
Was in a rush when I wrote that. Could’ve worded it better 😂
I’m safe. I don’t understand most of the words in this note.
> Users who triggered an error in Coracle while signed in with their private key, since December 5th 2023.
User login with extensions are not impacted?
Correct
@ hodlbod Does this note imply someone else had your bugsnap API key a couple of weeks ago?
hodlbod
Would whoever is running whatagent.net please remove my bugsnag api key from your deployment, it
"Would whoever is running whatagent.net please remove my bugsnag api key from your deployment, it's clogging up my error reporting."
🫂
What technically makes something like Amber more secure? I’ve never used it, so not familiar, but isn’t it just as vulnerable as anywhere else you stick your keys?
Thanks for confirming this
I feel a little bit better
thank you for the responsible disclosure and transparency. shit happens, glad you found it and fixed it.
Frostr will soon fix this!
View quoted note →You should be fine, that's exactly the point of using signer extensions: You don't give your private key to 3rd party websites, but websites instead request signatures from an extension.
That's why you should always use an extension signer like Nos2x-Fox when signing up on different web clients...
"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."
hodlbod
**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.
View quoted note →
If you used alby, you're safe.
I agree. More work is needed in this area.
If you’ve been dreading it then it’s been an ongoing issue.
Why didn’t you tell everyone initially when you found it? Genuinely?
Not judging you, seeking to understand.
Genuinely thought that was normalized already. Majority of entities have sock puppets. Even me. Mine are currently used for me to look back & analyze in chronological order.
Many are better about using multiple alts to express different parts of their personality or for narrative purposes. 🫂
You have hurt the First Peoples of Nostr
This week on #nostr.
@Vitor Pamplona wrote a piece on relay management
View article →
#AlbyGo 1.7 dropped
View quoted note →
#Yakihonne introduces smart widgets with 2.0.
@Derek Ross instantly jumped on it.
View quoted note →
@npub1wkrf...6xvg got some stats for us.
View quoted note →
#YakiHonne 2.0 is live
View quoted note →
@utxo the webmaster 🧑💻 announces Haven 1.0
View quoted note →
@iefan 🕊️ with a NostrHub update
View quoted note →
#BTCPay 2.0 has landed
View quoted note →
@walker goes all-in on #zapstream with the Bitcoin Podcast.
View quoted note →
@Alex Gleason is working on a new r3emote signer and nsec bunker
View quoted note →
Multi-million dollar NGO planning to use GrapheneOS
View quoted note →
@Maya Parbhoe talking about using nostr in Surianame
View quoted note →
Amazing drone show in Lugano.
View quoted note →
#Coracle security issue, reported fixed by
@ hodlbod
View quoted note →
@YEGHRO pushed an update to his inactive user tool. It now has bling!
View quoted note →
@fiatjaf merged something into #nostter
View quoted note →
/thread, Happy Weekend
