Deleted Account

Public Key

npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc

Profile Code

nprofile1qqswa8vhnelpgx9f7arjhtuzmjtqs2sdgfgmw77tzu9xankf87kl7eqprfmhxue69uhksctkv4hzuctrvd5k7mre9eek7cmfv9kqrasw3c

Publishing to

haven.accioly.social

Author Public Key

npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc

Show more details

Last Notes

2026-02-20 13:25:03 CET

@nprofile…fj80, morning mate, how are you? (Just doing NIP-01 as apparently NIP-17 is more broken than usual.) I was having a chat with @nprofile…dgdk the other day and started thinking: each one of us is maintaining a different SQLite driver for nostrlib/eventstore. What do you think about us joining forces and creating the ultimate super-duper SQLite3 driver? I’m happy to combine the features of all three repos into an initial version myself. I’m mainly looking for other folks who use it in their relays to help maintain it, as the more of us working on it, the better the driver will become and the more we can share the maintenance burden. I want Haven V2 to default to it with proper sane backwards compatible migration. Badger is gone from nostrlib, BoltDB sounds like more of the same and even LMDB will require a non backwards compatible migration. Thoughts?

2026-02-14 00:56:34 CET

@nprofile…xk05, am I welcome on your WoT Relay? :)

2026-02-07 17:18:09 CET

- reply

No problem, Utxo. Thanks for the zap, and I hope you are doing well!
I’m also working on improved backup and restore to finally move v1 into maintenance mode, and will reach out so we can decide what we are going to do about v2. Life got in the way since we last spoke but things are slowly starting to progress again.

2026-02-07 17:08:26 CET

- reply

CC: @nprofile…fzvp and @nprofile…vvjh

2025-12-29 16:18:01 CET

- reply

Agreed. I’m all for people unionising and for businesses being punished for union busting. I’m also against people being forced into unionising or being extorted into paying membership fees without real representation. Funnily enough, this is a posture that tends to annoy authoritarians on both the left and the right, as it makes too much sense. Unions can be a good thing, and when they are a good thing, people don’t need to be forced into unionising. Ask Brazilian finance professionals or US SAG-AFTRA members if they want to give up their union membership.

2025-11-10 14:49:32 CET

- reply

Aye, just to make myself 100% clear, I’ve got nothing against Keychat, and I can see how what you’re building would appeal to a lot of folks on Nostr. I’m also very much on board with the model of creating revenue for relay runners instead of, you know, zapping them 100k sats "prizes" to try and create goodwill. I heard nothing but praise from Nostr users towards Keychat so far.
That said, it’s not something I see myself using. Signal covers most of my chat needs. @nprofile…nggv got me back on IRC (noirc.net), which I’m enjoying for “dev” talk that doesn’t need to be private. If I ever need something truly trustworthy and private, I can always go back to self-hosting an XMPP server within a properly secured self-hosted environment behind a VPN.
Nostr devs as a whole won’t come together anywhere regardless; each will insist on their own NIP-29 or NIP-29ish approach and mostly just refuse to collaborate. So even if you nail the UX, revenue model, and everything else, that’s why I said that from my perspective, as amazing as Keychat can potentially be, given human behaviour, it will likely remain a niche tool for BTC and eCash enthusiasts.
Don’t get me wrong, though. I’m genuinely rooting for your success and for anything that strengthens user privacy in the messenger space. And extra kudos for building a model that properly discourages spam.

2025-10-21 20:32:27 CEST

- reply

I assume you’re Irish, correct? How cold is it in Ireland right now? Plenty of Nazis there, same as in the UK. The Justin Barretts and Scott Woods of the world are doing just fine. There’s plenty of money going into making neo-Nazism mainstream, and plenty of dumb people here in Europe who think they can’t find jobs or afford rent because of immigrants (while the very people sponsoring these neo-Nazism movements, Elon Musk included, are behind the collapse of their countries).

2025-10-11 14:23:33 CEST

- reply

This is amazing Girino, great stuff! My own version of Haven (not on GitHub for now) is also running a custom build of SQLite in WAL mode, with better indexes, json1 functions, improved upserts for replaceable events, and a few other tweaks.
I didn’t denormalise data like you did (still one big table) and am still exploring concurrent writes (https://www.sqlite.org/src/doc/begin-concurrent/doc/begin_concurrent.md). Basically, I’ve reached the same conclusion as you: I’m getting lower latency and higher throughput, even at levels of concurrency that would be unrealistic for personal relays. For large WoT relays write contention can become an issue at some point; but that’s what PostgreSQL and LMDB are for.
Maybe in the future we can join forces and publish a solid SQLite "eventstore driver" compatible with nostrlib ("go-nostr + khatru v2" if you’re not aware of it)? That seems to be the Fiatjaf-approved way ("write your own eventstore drivers, mere mortals"), and it would give us more control over migrations.
I honestly don’t want to migrate Haven users from Badger to BoltDB, even if it would be the path of least resistance to adopt nostrlib.
@nprofile…6u4e (I haven’t forgotten about you or our chat; just absolutely swamped with real-life stuff, apologies). I’m more and more inclined to thing that a custom SQLite driver is the way forward for the whole nostrlib migration effort. Maybe even a PostgreSQL driver for the algo relay. Old-school SQL is officially the new cool 2025 Nostr dev trend (and I'll keep repeating this until it becomes reality lol). :)
#nevent1q…8mff

2025-09-26 04:34:20 CEST

- reply

#nevent1q…yhkq

2025-09-17 18:49:04 CEST

- reply

Oi Hertu, olhando seu perfil eu acho que você é brasileiro, confere? Fique a vontade para escrever em português se quiser. A gente se entende ( translate.kagi.com/ salva :)).

2025-09-10 11:33:25 CEST

- reply

We are in a weird timeline... I mean, I agree with you that, as things stand, Europe needs to increase military spending and European countries need proper armies (hopefully developing their own military tech in the process, rather than sending money to the US military-industrial complex like Trump wants).
But honestly, I wish we were in a different timeline, one where the world was still integrating and mutual trust and understanding were possible.

2025-09-08 20:16:49 CEST

- reply

I definitely have plenty of pain and confusion to contribute 🤣🤣🤣. Thanks for trying to bring some method to the madness.
Apologies for the question, but is there an organisation behind Nostrability? It sounds like an attempt to do some QA / PO / PM work across “everything Nostr.” Which, don’t get me wrong, is very welcome and much-needed work. Thanks for your service!
But my question is: is someone funding it? Is this effort sponsored by grants or by companies running Nostr businesses, or something along those lines?

2025-09-08 19:17:29 CEST

- reply

Interesting thread. Thank you.

2025-09-06 03:25:57 CEST

GN Nostr. Today (well, yesterday) was a good day 🛌😴🌙

2025-09-03 20:15:13 CEST

- reply

I honestly don’t know. User activity levels vary substantially, there are different kinds of notes beyond just short and long text, and a single black swan event such as “Reply Guy” or even a misbehaving client can drastically change the outcome. Maybe folks running WoT relays, such as Utxo and @nprofile…4t0k can give you a better idea.

2025-09-02 01:37:32 CEST

- reply

Obrigado pela lembrança, Girino! @nprofile…266u I'm happy to have a chat, feel free to DM me. Even if this one isn’t for me, I can probably at least point you in the right direction.

2025-08-30 12:54:36 CEST

- reply

Culture is probably the real issue behind the discoverability problem. Sure, we can improve things with curated feeds, follow packs, etc. But if people actually followed hashtags and built a culture of boosting good content, like on Fedi, it would naturally surface on everyone’s feed. The problem is that the typical Nostrich follows the same small set of accounts and only looks at the top of their follows feed or, at best, Primal’s trending topics. Folks need to understand that on decentralised social media with linear feeds, sharing is caring.
PS: To make this more constructive and actionable rather than just a rant; instead of "Why don’t anons follow hashtags and boost good content?", I’d love to see something like a curated Art feed, à la https://dev.nosotros.app/feed?relay=wss%3A%2F%2Frelays.land%2Fspatianostra, curated by people like @nprofile…adm8, @nprofile…c49d, etc.
Not sure if you have the time or interest, but @nprofile…xuyp has been looking to bootstrap more curated relays; and an art-specific one would be awesome.

2025-08-24 19:16:22 CEST

- reply

And slowly turn your face both ways with shoes on your head. I can totally see this happening 🤣🤣🤣

2025-08-20 10:13:32 CEST

- reply

Apologies again, but just to remove any ambiguity: when you say "for picking your own relay", what exactly does that mean? Is this something only for you (Mike) to filter writable relays? How is Gossip actually using the resulting list of vetted relays for its users, if at all?
For example, if I have a brand new, non-
NIP-11 compliant relay with a non-standard path tagged in my Kind 10002:
```
["r", "wss://brando-relay.com/inbox", "read"],
["r", "wss://brando-relay.com", "write"]
```
This is the first time that Gossip encounters brando relay. Will it:
1. Write my own kind 1 notes to wss://brando-relay.com/?
2. Write other users’ notes tagging me to wss://brando-relay.com/inbox?

2025-08-19 14:40:42 CEST

- reply

Pesky persistent bug. Go to settings and click "Delete local cache". v3.4.6 should show up.

2025-08-19 01:37:27 CEST

- reply

I didn't know that sandwich has behind nostr.watch :).

2025-08-19 00:33:49 CEST

- reply

Thanks for your help Beave!

2025-08-18 23:27:45 CEST

- reply

CC: @nprofile…6u4e, @nprofile…vhu6, @nprofile…xuyp

2025-08-18 23:26:57 CEST

Hey Nostr, I hear you like vlogs now… so I’m completely ignoring the trend and releasing **Haven v1.1.0** instead. 😂
https://github.com/bitvora/haven/releases/tag/v1.1.0
https://haven.accioly.social/a6b87db33cd059d61b2b95bd7e02de6ab725d29949cf245e21aaa7b653088a78.png
This release is packed with lots of bug fixes and plenty of background work paving the way for v2.0.0. It also has a few new features. Here are the main highlights:
1. Signed binaries: no need to install Go, build tools, or compile Haven yourself anymore (at least if you’re on Linux, macOS, or Windows with a x86-64 or arm64 CPU).
2. Improved import logic: Haven should crash less and no longer get stuck during imports. My own instance has been running crash free for 26 days. Logs also provide clearer info when Haven can’t connect to relays, so if you’ve unreachable relays in your `relays_import.json`, now’s a good time to fix this.
3. Blossom media: Support for deleting media, plus a bug fix that lets the Primal Android client mirror media to and from Haven on mobile.
4. Blossom Blob Descriptors: migrated to a separate database and no longer queryable from the Outbox relay.
⚠️ Breaking change: If you’re upgrading from v1.0.5 or earlier, you may hit a BadgerDB migration issue. Please back up your database before upgrading. If you see
```
error running migrations: failed to delete index key 07935dc9483d36f24464b36e6c000001b9: Txn is too big to fit into one request
```
Delete the `db` folder and reimport your notes.
Huge thanks to @nprofile…4t0k, @nprofile…k6x3, @nprofile…h5pr, and @nprofile…9vt4 for alpha testing, troubleshooting, and helping me improve the docs.
Enjoy!
#Haven #newRelease #Nostr #growNostr #relay #personalrelay

2025-08-17 01:49:15 CEST

Good night, Nostr. I hope you’re having a great weekend.
Here’s an interesting discussion about binding arbitration and the degree of freedom we enjoy here on Nostr compared to other social media networks:
@[email protected] 🔗 https://mastodon.online/users/mastodonmigration/statuses/115040517122921946
- Bluesky now has a binding arbitration clause as part of their ToS. Users hate it. There’s nothing they can do about it. There was massive user backlash. Complaining won’t solve the problem. Bluesky belongs to a company. Protecting investors comes first. Users are the product.
- Mastodon attempted to do something similar. Got a ton of backlash from users and paused the initiative. Unlike Bluesky, Fedi users are way more likely to move to alternative tech (be it based on ActivityPub or not)
- Nostr: I can’t think of anyone even trying to do this. I mean, who are you going to sue to begin with?
TL;DR: Use a social media network where you aren’t even sure who you could sue or persecute if you disagreed with something. Use a social media platform you can build yourself. Use social media where you own the content. Make sure you (not anybody else) decide what to boost and who to mute.
#SocialMedia #FreedomOfExpression #Nostr #GrowNostr #Bluesky #Mastodon #GoodLuckWithYourArbitrationClause

2025-08-12 00:38:38 CEST

- reply

Well, unfortunately I can't release the Kraken today (technical issues with the CI pipeline and I'm too sleepy to fix it). Hopefully tomorrow!

2025-08-11 16:40:30 CEST

- reply

Off you go then. You certainly don't need my permission for anything. I'm sure that the new state that you are all proposing will not be in debt, stripped of its resources, and held hostage by the exact same mix of global private enterprise and local corrupt yes-man government as today (just in slightly different clothes). I'm sure that Alberta will not, at best, end up as yet another lapdog of the biggest bully around, just like Canada, the UK, and, you know, every other state since the beginning of modern written history. Because… you are different! Better, stronger, wiser, and harder working than everyone else who has ever attempted this. Things will certainly go the way you expect, purely through the sheer might of the local people's willpower. Creating more state is the solution. A new, smaller state what will certainly be different than every other state ever created.
https://youtube.com/shorts/hDy5czc1qq4

2025-08-10 20:52:05 CEST

- reply

Entendi. Ainda assim é estranho... Tipo, subir o kind 3 de outras pessoas para o seu relay não afetaria o conteúdo do seu próprio kinf 3. Para rolar essa salada você teria que assinar um novo evento que adiciona a pubkey desses estranhos ao seu kind 3. Enfim, eu já vi clientes fazendo coisas bizarras com essas listas (já vi até XML dentro dos eventos lol). Mas enfim, pelo menos a sua chave parece não ter sido comprometida. É isso que importa! E obrigado movemente pelos testes

2025-08-10 19:55:52 CEST

- reply

Faz sentido. Usando /haven --import o haven carrega o kind 3 mais recente dos relays que você configurar no arquivo de import. Mas se você assinou um kind 3 mais novo é isso que ele vai importar. De qualquer forma, se você achar um kind 3 antigo no Citrine ou qualquer outro relay pode assinar novamente e o Haven vai importar sem problemas. Se você não tiver o Citrine, adicione o relay do Semisol abaixo que ele prove a mesma funcionalidade. No futuro você pode restaurar sua lista de seguidirrs em um passo ao invés de sair caçando kind 3 antigos em um bando de relays e ter que assinar uma nova versão manualmente.
Realmente gente que você não conhece na follow list é estranho. Por outro lado acho que se sua chave privada tivesse sido comprometida mesmo eles fariam mais do que bagunçar os followers. Muito provavelmente algum se confundiu com a sua restauração de lista e fez alguma coisa doida.

2025-08-04 03:56:48 CEST

- reply

Hey Girino, yes. Unfortunately, this is the same error that @nprofile…k6x3 reported here: https://github.com/bitvora/haven/issues/85 — which I also faced myself.
I don't have a better workaround than copying the current database somewhere, starting fresh, and running /haven --import again. (You can even start two instances of Haven and use the second one to import from the first if you don't have a copy of your notes on other relays.)
I looked into the possibility of breaking down Khatru migrations into smaller transactions, but it's not a trivial thing to do. After speaking with Fiatjaf, it seems there isn't much appetite to tackle this, as it would substantially complicate the migration logic.
In the future, I hope to provide more robust Haven backups along with proper "restore from backup" functionality as an alternative to the current import mechanism. I'm also planning additional support for relational databases such as SQLite and PostgreSQL, where migrations are a much easier problem to solve (and easier to work around on Haven's side if anything breaks in EventStore).
Apologies that I don't have a better "solution" for the issue, but hopefully the re-importing gymnastics won't be too bad.

2025-08-01 17:52:51 CEST

- reply

Yeah. That’s where I want to go with Haven as well. Having a nice, private UI where you can say:
* This person is trustworthy; let their followers write to my relay.
* This person? I don’t know. If three other folks follow them, then let them write to my relay (default).
* This other person? I love them, but they follow bots and weird people, so their follows don’t get write access to my relay.
This is all private and livsl.
I’m running a private fork of Haven with a barebones implementation of this. No UI, just local files with npub / trust-level pairs, and so far it’s sorta working for me.
It’s still essentially a dumbed-down version of PGP ownertrust, but (hopefully) something that can br done in a way that’s more intuitive and attractive to normies than the whole PGP “signing key party” stuff.

2025-07-30 12:30:37 CEST

- reply

Thanks! Intention is what matters. Currently my lightining address is redirecting to Wallet Of Satoshi, it seems to be online and working well...
429 usually means you / your client is being rate limited (too many requests). If you're still having issues, could you let me know which Nostr client you're using?

2025-07-30 00:16:31 CEST

- reply

Yes, it can. The short-term "right" fix here is to start small and grow the MapSize on demand, which, again, may or may not preallocate space got the DB file depending on the OS, filesystem, and architecture. For example, on Windows and macOS ARM, the initial MapSize has to be smaller than the available disk space, but once it has started (despite file managers displaying a 273GB file) it’s not actually using that much disk space.
I considered implementing dynamic growth in Khatru’s EventStore, but it’s a reasonably complex, non backwards-compatible change. And when I discussed it with Fiatjaf, it seemed there wasn’t much appetite for it.
There are other LMDB forks/wrappers that handle this more gracefully, so Fiatjaf is probably right. The best long-term approach is to migrate db libraries or db technology altogether. That would likely also help with some other Khatru issues around migration, transaction size, etc. But that’s a separate conversation.
The static MapSize parameter is good enough for Haven’s needs, and I assume for most other Khatru relays as well. Relays with the pretension (or real need) to scale on demand, potentially to petabytes in an enterprise DB cluster won’t be well served by EventStore, and to be honest, not even by Khatru in its current form.
Still, that would be a good problem to have, and right in my area of expertise (Distributed Data-Intensive Systems) when we get there. Semisol is already building something along those lines, so he’ll likely be the one pioneering this kind of thing on Nostr.

2025-07-29 14:20:53 CEST

- reply

Fingers crossed yes. But when politicians, lawyers, etc are involved… Who knows? I think that public relay operators like @nprofile…dx2g will test the waters first. But I really wonder what's everyone plab will be (if any).

2025-07-25 16:17:59 CEST

- reply

Not sure if you've already fixed Alby, but it looks like you've set your cash address as your NIP-05 (which is a separate thing meant to be a sort of user handle). Your Lightning address is still pointing to Alby.
If you don't mind telling. How many sats have you lost so far?

2025-07-25 13:44:57 CEST

- reply

VC/PE in a nutshell.
Full disclosure: I used to work for investment banks (as a techie; not front office, M&A, or anything fancy but close enough to interact with VC and PE folks). I still get a personal laugh out of all the finance bro memes here on nostr, especially when folks end up parodying the very finance culture they mock.
Add some laser eyes and a (a conveniently curated to allow him to profit from fiat) cypherpunk persona to the finance bro in a jumper meme, and you get the stereotypical Nostr VC-backed crypto bro.
The difference is mainly that some people in traditional finance are actually making money out of it.

2025-07-25 12:21:59 CEST

- reply

Agreed to an extent. Crucifying devs for something that’s mostly out of their control (it would be a nice world where devs and product folks could actually predict how people use their software) isn’t productive. So, to be clear, I don't think mobbing devs is the way to fix this! Especially since I’m not a believer in algorithmic solutions to complex social problems.
However, I disagree with the "bad vibes bring bad vibes" argument, especially since the toxic Nostr monoculture block isn’t exactly passive either. They don’t just exclude you for saying something that goes against the grain. They ruthlessly sabotage people with different ideas, all so that the "GM Pura vida 🤙🤙🤙" bubble can keep monopolising the Nostr trending lists and pushing the same rehashed marketing over and over and over again, scamming users out of their first 10k sats or so to buy services they don't need.
Refusing to talk about it or call it out just because "every dev already knows" reinforces the idea that everyone on Nostr is fine with it… or worse, that everyone’s part of it. New users don’t know what we know.
Voicing user concerns, or at least showing some agreement, helps avoid churn. It shows there are real humans who care behind the machine.
I could ask AI to create a more explicit illustration of what I think about the whole "let’s just not talk about it" situation, but hopefully this family-friendly version gets the idea across.
https://haven.accioly.social/a380aa7abd7bed9dec72dc1b80774311312609d489324050c19735a0d6920426.png

2025-07-25 11:46:24 CEST

- reply

There are dozens of us. Thank you for your service, @nprofile…56gx. I appreciate your efforts as well. There's very little appreciation for independent devs on Nostr, and we should be more vocal about it.
Agreed, the business model for BTC/Lightning solutions marketing to new users will eventually eat itself. And I don’t mean in Ouroboros style (at current churn rates, there’s very little money to be made from naive new users anyway).
The bad news is that with its downfall, some of the funding keeping Nostr software alive will likely disappear. The good news is that… well, there are dozens of us trying to keep Nostr alive, regardless of financial incentives.

2025-07-25 10:53:30 CEST

- reply

GM verbiricha. Agreed. I have an interesting relationship with Nostr myself. It's been a while since I’ve spent this much time on any social media. The protocol itself is genuinely interesting, but…
Honestly, in a year, I’ve made very few meaningful connections. There are maybe a dozen people at most who even try to interact with me about anything (aside from technical support for HAVEN, I mean).
The fact that I’m not a Bitcoin maxi (and am vocally allergic to the scammy behaviour of some of the Nostr celebrity accounts pedalling paid services and "Bitcoiner busy boxes") doesn’t help either.
And yes, the culture of shutting down any "unapproved" ideas, only to later adopt them once one of the Nostr celebs "endorses" the criticism, is really annoying. It’s funny, for a bunch of folks who see themselves as free-thinking, sovereign, libertarian techno-enthusiasts, bla bla bla, most of the few humans still on Nostr act like a bunch of 🐑🐑🐑🐑🐑.
I hope that one day, when someone mentions Nostr’s toxicity and its 20-year-old-crypto-bro monoculture, I can reply with something other than “Yes, but…”.
The best I can do right now is:
“Yes, but… there’s also half a dozen artsy and techy folks mostly talking to themselves with hashtags that I really like. Plus Japanese Nostr.”

2025-07-25 03:44:30 CEST

- reply

@nprofile…6u4e, FYI.

2025-07-05 15:54:32 CEST

- reply

I forgot to share a link to Omarchy. Here you go: omarchy.org/

2025-07-04 13:42:07 CEST

Test

2025-07-01 12:44:12 CEST

GM Nostr.
Hint of the day for the devs out there: I was heavily reliant on Dependabot to keep my project's software versions up to date (you are keeping your dependencies up to date, right?).
Some colleagues who are deeper into OSS told me to try Renovate, but I mostly dismissed it as just alt tech.
Now that I’m working on some software outside of GitHub, I decided to give it a go. And I have to say: folks were right. Renovate is just... better. It does pretty much everything I need out of the box, and it avoids a lot of manual work or extra CI steps that Dependabot requires.
Here are some of my favourite features (in no particular order):
- Works much better with monorepos out of the box
- Great (and I mean it) presets
- Has a nice dashboard to track what's going on
- In the JVM ecosystem, it upgrades Gradle and Maven Wrapper versions
- Same for Go, it upgrades the Go version in `go.mod`
- It can pin versions in ecosystems where that's best practice (including, somewhat Ironically, GitHub Actions)
- Has better confidence metrics and update recommendations compared to Dependabot
- First-party integration with OSV (though you can also use GitHub’s Advisory Database, which, credit where it's due, is a great and convenient resource)
- Requires way less YAML fluff to auto-approve and auto-merge PRs after CI passes (assuming you do have proper tests and checks running, right? Right???)
And the big one: it works everywhere.
On most platforms Renovate already offers its own Bots and integration tooling, but you can also use the CLI or even run / selfhost your own bot.
In most cases, all you need to do is install the Renovate bot and drop a `renovate.json` like the one below into your repo. Then just sit back and watch the magic happen.
https://haven.accioly.social/2f06a6afa7b48ebbdf662ff94e8896a511f37e9f71ccf524a1fe1b885a532a80.png
You can customise a gazillion settings to your heart’s content, but unlike GitHub Actions + Dependabot combos, I didn’t need to write loads of config to get it working the way I wantm My go-to `renovate.json` is just 5 lines of config at the moment.
Definitely worth checking out:
https://docs.renovatebot.com/
#gm #devstr #devops #renovatebot #oss #dependabot #automation #softwaremaintenance #ci #monorepo #buildtools #developerexperience #selfhosted

2025-06-25 08:57:25 CEST

- reply

If you can keep a list of CF-Worker headers, the more people reporting the script kiddies the better. Some traffic may be legitimate like Semisol stuff above. But on my side the fast majority of traffic are WordPress, router and admin panel attack attempts. The more people reporting those folks the better. At some point CF will have to connect the dots.

2025-06-25 08:35:44 CEST

- reply

Yeah. This is a bizarre one. And it has increased substantially. I had like 500k hits the very first day. Yesterday it was over 10m.

2025-06-25 00:48:45 CEST

- reply

Do I need an invite or something?
https://haven.accioly.social/80c3dd778e64b3f1d03f2cbb1dd65bb86d157d45aa998e8bef37271f675b7515.png

2025-06-25 00:48:15 CEST

- reply

Do I need an invite or something?
https://haven.accioly.social/80c3dd778e64b3f1d03f2cbb1dd65bb86d157d45aa998e8bef37271f675b7515.png

2025-06-25 00:44:16 CEST

- reply

Agreed, kind 1 is awesome but... Not exactly the best place to share 20+ loc bash scripts about exotic issues on nak NIP-46 support. Plus hard to follow up what everyone is doing. I'll join your community :)

2025-06-25 00:34:55 CEST

- reply

I'll have a look at rely. And yes, EventStore deserves a rewrite. Again, we should have some sort of channel to discuss this kind of thing. It's a "small" group of devs but not small enough that I can keep up with what everyone is doing. A NIP-29 group or equivalent would be awesome, it can even have a bigger scope than just Khatru based relays.

2025-06-24 22:00:05 CEST

- reply

I'm aware… Well, both relays are written in Go and Khatru based. Plus, hodlbod here is good people. So, on my side, I have absolutely no issue with you two merging both initiatives and, on my side, will be happy to contribute in any way I can. We just really, really need a place for Khatru based relay devs to align. So whatever relay software you folks decide to stick with, let’s create a community please 🙂
Speaking of stretched devs, when you have a chance, could you please read my DM? hzrd149 has merged my changes to the Blossom specs (type is no longer optional in the Blob Descriptor, and the whole redirection thing is in place 🎉), so I’ll finally be going back to Khatru redirection support, followed by Haven. I’ve also got sidequests on mak, Song, and possibly njump (plus an experimental Blossom/IPFS bridge I’m working on myself that may or may not be made publicly depending on how well it works :)). If I could get 15 minutes of your time at some point, it would help me immensely.

2025-06-24 15:13:26 CEST

- reply

I think that there's room for more than one NIP-29 around, assuming that there's enough community interest and dev capacity for it. At the moment I'm struggling to get anyone even remotely interested in it. Lol

2025-06-24 11:28:51 CEST

- reply

Let's see what we can do about it. Haven is worning well with NIP-17, but I can't expect everyone on Nostr to install it, lol. Apparently other folks are already building NIP-29 relays. Clients are also evolving, so we may be in a different situation soon.

2025-06-23 13:54:32 CEST

- reply

Thanks w!

2025-06-23 12:36:45 CEST

- reply

I really, really want to be excited about NIP-29 (and Chachi is amazing, by the way).
Still, my own journey came to a very early end when I accidentally left a community that I created myself, and now I can't get back into it.
https://chachi.chat/groups.0xchat.com/3081bdbb1b5bde3c2ace7ed4446e6a9cd11a2907e9d86ede95ae8224d50d350f
According to @nprofile…rts7, there's a bug in the underlying relay software where leaving a NIP-29 group = permanent ban. (I’ve already tried to summon @nprofile…xuyp a few times about it, but my skills as a fiatjaf summoner have been weakening.)
Between this and the fact that most folks ignore or don’t even receive NIP-17 messages on Nostr, it’s still hard to recommend NIP-29 to people currently using Discord, Slack, Matrix, etc., to run their communities.
Hopefully folks like you and @nprofile…t8ky will keep pushing this forward. But I do think the relay side of things needs to catch up a bit. One more side quest for me if I can get other folks interested, lol.

2025-06-19 22:11:34 CEST

- reply

I'm old school, so I still call it MD5momile 🤣.

2025-06-17 23:13:51 CEST

- reply

@nprofile…t8ky, telll em that groups.0xchat.com is not running relay29, pretty please?
@nprofile…xuyp, what I'm asking you to do is to join
groups.0xchat.com'3081bdbb1b5bde3c2ace7ed4446e6a9cd11a2907e9d86ede95ae8224d50d350f on your favourite NIP-29 client.
#naddr1qp…8v3g
I made you admin there before I accidentally left th3 relay. Now I can't rejoin lol. My hope is that you as an admin could accept my join request. And now this is also an upvote for the issue above.

2025-06-17 23:04:57 CEST

- reply

https://youtu.be/3WAOxKOmR90

2025-06-17 23:00:12 CEST

- reply

Permaban meaning that even if another admin accepts my join request I can't come back? 🤣🤣🤣
That's a fun one

2025-06-12 19:16:07 CEST

- reply

If I'm not mistaken Amethyst has killed push notifications no? Do you really need it? IMO a pull model a la @nprofile…7edf's Pokey, while not necessarily the most resource efficient way of doing things, is the safest and easiest way to deal with encrypted stuff. IMO, what we need is a "Desktop" or "Browser extension" equivalent of Pokey.

2025-06-12 19:13:49 CEST

- reply

If I'm not mistaken Amethyst has killed push notifications no? Do you really need it? IMO a pull model a la @nprofile…vdel's Pokey, while not necessarily the most resource efficient way of doing things, is the safest and easiest way to deal with encrypted stuff. IMO, what we need is a "Desktop" or "Browser extension" equivalent of Pokey.

2025-06-12 10:52:17 CEST

- reply

Lol, apparently I clicked on something and left my own group and can't join back. @nprofile…xuyp, sorry to bother you. Can you approve my join request 🤣🤣

2025-06-12 10:44:41 CEST

- reply

Hey @nprofile…rts7, the UX is looking great. Very Discord / Slack / Matrix Elements like.
Interesting enough, the NIP group that I've created yesterday using 0xChat isn't showing up on search. And when I do join manually it asks me if I want to join (which is funny since I'm the creator).
Is it because it's a closed group?
https://app.flotilla.social/spaces/groups.0xchat.com/3081bdbb1b5bde3c2ace7ed4446e6a9cd11a2907e9d86ede95ae8224d50d350f

2025-06-10 18:12:18 CEST

- reply

Got it, many thanks! I made the wrong assumption that relay.ngit.dev was only advertising the original repo. I didn’t realise it was storing its own copy.
Thanks again. Can I ask one last question, just to make sure I understood things correctly?
If I use ngit to initialise my repo (originally hosted on GitHub) to both relay.ngit.dev and gitnostr.com, then in theory all three servers have a totally independent copy of the repo, right? (i.e. this is pure Git, with no background sync or anything like that)
Actually, the question behind the question is: nothing stops someone from creating a change and only pushing it to GitHub. So, in this case, if I want those changes to be visible on relay.ngit.dev and gitnostr.com, it’s up to me to push the changes there manually or set up a third party sync / mirroring solutionl, correct?

2025-06-10 13:54:04 CEST

- reply

Makes absolutely sense. Thanks!
Just to clarify my understanding then (and apologies for so many questions, NIP-34 is still a bit Greek to me).
Say that I have a repo on GitHub. I made an announcement to relay.ngit.dev and later deleted my GitHub repo.
If someone had cloned my repo using the relay.ngit.dev url before I nuked my eepo then they would be able to open a PR as per your post above correct? But will they be able to clone the original content using the NIP-34 repo uri after I nuked my original repo? I'm just trying to understand if nuking the git repo isn't a left-pad situation by itself regardless of the announcement note existing or not... If it is, maybe adding a button to delete the announcement to GitWorkshop wouldn't be that big of a deal.

2025-06-07 19:37:05 CEST

- reply

This looks very promising, thanks!
https://github.com/franzaps/zapthreads
Looks like @nprofile…u0w6 built a share button as well:
https://github.com/coracle-social/nub
Between the two I think that I have a basis for what I need.
It would be awesome to have a combination of widgets that folks could use to turn any blog into something a la micro.blog (i.e., with support for Nostr and ActivityPub at least).
Side quest #278 to come back to one day if someone else doesn't vibe code it in five minutes while I take forever thinking about it 🤣.

2025-06-07 19:34:20 CEST

- reply

This looks very promising, thanks!
https://github.com/franzaps/zapthreads
Looks like @nprofile…u0w6 built a share buttons as well:
https://github.com/coracle-social/nub
Between the two I think that we have a basis for what I need.
It would be awesome to have a combination of widgets that folks could use to turn any blog into something a la micro.blog (i.e., with support for Nostr and ActivityPub at least).
Side quest #278 to come back to one day if someone else doesn't vibe code it in five minutes while I take forever thinking about it 🤣.

2025-06-07 15:20:34 CEST

- reply

Makes sense for sure. Assuming that you are selfhosting your wallet and Nostr client over that same tailnet, this is a great way to zap with a bit more safety.

2025-06-07 14:35:14 CEST

- reply

Yeas, this is doable for sure. We can also require auth + disallow "dangerous" queries... The "wallets won't cooperate" is a harder problem though. I think that we can try to create our own nostr+connect urls pointing to Haven relay + the relays that wallets are listening on so that we at least get a copy of the pay_invoice command. But we need wallets to cooperate a bit for basically everything else. I guess that having a copy of Kind 23194 is better than nothing. But I would like to have a copy of the responses, notifications, etc as well.

2025-06-07 14:17:39 CEST

- reply

I have an ongoing POC running locally. I haven't found a better way than whitelisting/blacklisting NWC-specific nostr+walletconnect:// URIs or random npubs encoded in them. Either that, or leaving the relay completely open, which is... not great.
The second issue, for basically everyone except wallet/NWC payment service developers, is that there's a lot of back-and-forth between the wallet and the relay. The wallet also needs to be configurable enough to forward events to your specific relay (many aren't). Most won't even allow external tools to query all NWC-specific events, so we can't even use the same subscribe/import trick we're using for kind:1 events. This is why I haven't committed my POC upstream yet. I haven’t found much use for end users, unless the user has full control over their NWC stack. And if they do, they can use your other relay.
Hopefully we can convince more custodial wallet devs to allow users to use their own payment relays in the future. This would make private payment relays much more useful to end users.

2025-02-13 11:01:03 CET

- reply

It's shaping up nicely! Can I make a suggestion? This might require some changes to khatru itself since it doesn’t expose the HTTP response object to the LoadBlob function, but it would be great to have an option for Cloud storage to redirect to public buckets or CDNs on read (i.e., send an HTTP 301 or 302 response) instead of "proxying" the request if you get what I mean.
https://github.com/hzrd149/blossom/blob/master/buds/01.md#get-sha256---get-blob
@nprofile…wj75, quick question to make sure that I understand BUD-01correctly. When using code 301 with Blossom, while the URL should expose the sha256, there's no requirement for the file in question to be at the root at the redirected URL right? I.e., it should be fine to redirect to an URL such as
https://www.myblossomserver/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553 to https://s3.us-east-2.amazonaws.com/myawesomebucket/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553 right?

2024-11-11 10:38:42 CET

- reply

nip05 domain-wide blocking with "hidden words" isn't working for me (Try to add `mostr.pub` to the hidden words and switch to Global - warning Mostr is pumping a lot of awful stuff across the bridge and isn't representative of most Fediverse content at all).
Amethyst folks are already working on this. I'll try to build the PR later today.
#nevent1q…smax
I'm still looking for an solution for noStrudel though.

2024-11-10 02:04:07 CET

- reply

nip05 domain filtering maybe? (Extract note author's pubkey, query associated kind 0, if nip05 key contains `mostr.pub` discard note). Not a general solution, but likely good enough to mute Mostr and other gated NIP-05 enforcing communities.

2024-11-10 01:30:18 CET

- reply

Thanks for the suggestion Dee Kay. Here it is: https://github.com/vitorpamplona/amethyst/issues/1173

2024-11-09 20:06:48 CET

- reply

Unfortunately no joy. Apparently hidden words won't match partial NIP-05 addresses.

2024-11-09 19:59:22 CET

- reply

Thanks! I’ll try this before dynamically building a mute list. Individually blocking every Mostr NIP-05 address doesn’t seem very practical—it would likely create a massive mute list, and I’m not sure how well clients would handle it. I’m already having issues with a much smaller mute list.

2024-11-03 15:47:54 CET

- reply

I'm not sure what library you are using and if you are using a Bundler. The easiest way is to directl import a bundle like nostr-tools (ot at least this was the easiest way for me as fellow "I dont know what I'm doing" mostly backend person):
https://github.com/nbd-wtf/nostr-tools?tab=readme-ov-file#using-from-the-browser-if-you-dont-want-to-use-a-bundler
Otherwise you can just install the library, import it and use NIP-07 TS types:
https://github.com/nbd-wtf/nostr-tools?tab=readme-ov-file#including-nip-07-types

2024-11-01 16:28:37 CET

- reply

This one is on me Ben. Don't worry, Haven will have proper CORS support OOB soon. I just need some patience as I'm travelling and working on a gazillion other things at the moment and I want to get this right.

2024-10-18 00:04:07 CEST

- reply

@nprofile…qnju stats

2024-10-12 12:56:31 CEST

- reply

@nprofile…qnju stats

2024-10-07 12:09:48 CEST

- reply

@nprofile…qnju stats