Deleted Account

Public Key

npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc

Profile Code

nprofile1qqswa8vhnelpgx9f7arjhtuzmjtqs2sdgfgmw77tzu9xankf87kl7eqpypmhxue69uhksctkv4hzuctrvd5k7mre9eek7cmfv9kz76twvfhhsqgjwaehxw309amk7apww468smewdahx2yq72dr

Publishing to

haven.accioly.social/inbox

Author Public Key

npub1a6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajq7w0tyc

Show more details

Last Notes

2026-02-21 19:21:00 CET

And with this, I have an announcement of my own. Having left Haven in a good state, with an easy way to export data through JSONL to other relays, including the new work thatn@nprofile…r7ku is building, I’m retiring this npub and my presence on Nostr Kind 01 permanently.
At this point, Haven is robust, battle tested software used by hundreds of relay operators. I’m sure that, other than for potencial incompatible changes to the Nostr protocol, it should remain solid for, well, longer than it has even existed.
The V2 / nostrlib version that I often spoke about will not happen, at least not for now, and likely not under mine or utxo’s guidance. But, as utxo said, I have been working hard to give users most of the features they asked for before putting Haven into maintenance mode. Well, it is finally time... I will, of course, still keep an eye on GitHub for bugs, and I’m sure that the many developers who forked and contributed to Haven will maintain their forks and carry the torch. Maybe they will elect a new official fork, or at least keep their versions alive until users are ready to move on to the future vision that utxo, Fiatjaf, and other Nostr developers are building. At Nostr’s pace, this should not take long anyway.
Before I NIP-62 and NIP-09 my Nostr presence out of existence (at least on well behaved relays willing to respect my wishes), I just wanted to leave my contact details for anyone who would like to stay in touch.
I’ll keep my presence on ActivityPub / Mastodon, although I do not post there much:
https://accioly.social/@anthony
I’m also still on @nprofile…7nrg’s noirc.net (nick: anthony) and in some Libera.Chat (aaccioly) channels. If you are an IRC enthusiast, I’m happy to chat there.
Finally, I’m on Signal / Molly if you would like to speak directly:
https://signal.me/#eu/cDGXbPN8BUyAyyhJ4LjhTxdftVPixKjvZ-IDdrN-QhTrPYC3lotILLNJE8RKlHom
I’ve met some incredible people on Nostr and would genuinely appreciate ways to stay in touch outside of it.
#accountRetirement #shrinkNostr?
#nevent1q…e2n5

2026-02-21 18:45:11 CET

And with this, I have an announcement of my own. Having left Haven in a good state, with an easy way to export data through JSONL to other relays, including the new work that @nprofile…r7ku is building, I’m retiring this npub, and my presence on Nostr Kind 01, permanently.
At this point, Haven is robust, battle tested software used by hundreds of relay operators. And I’m sure that, other than ror incompatible changes to the Nostr protocol, it should remain solid for, well, longer than it has even existed.
The V2 / nostrlib version that I often spoke about will not happen, or at least not at the moment, ans likely jot under my or utxo’s guidance. But as Utxo said, I have been working hard to give users most of the features they asked for before putting Haven in maintenance mode. Well, it is finally tie :). I will also keep an eye on GitHub for bugs, and I’m confident that the many developers who forked and contributed to Haven will maintain their forks and carry the torch. Maybe they will elect a new official fork, or at least keep their versions alive until users are ready to move on to the future vision that utxo, Fiatjaf, and other Nostr developers are building. At Nostr’s pace, this should not take long anyway.
Before I NIP-62 and NIP-09 my Nostr presence out of existence, at least on well-behaved relays willing to respect my wishes, I just wanted to leave my contact details for anyone who would like to stay in touch.
I’ll keep my presence on ActivityPub / Mastodon, although I do not post there much: https://accioly.social/@anthony
I’m also still on @nprofile…7nrg’s noirc.net (nick: anthony) and in some Libera.Chat (aaccioly) channels. If you are an IRC enthusiast, I’m happy to chat there.
Finally, I’m on Signal / Molly if you would like to speak directly:
https://signal.me/#eu/cDGXbPN8BUyAyyhJ4LjhTxdftVPixKjvZ-IDdrN-QhTrPYC3lotILLNJE8RKlHom
I’ve met some incredible people on Nostr and would genuinely appreciate ways to stay in touch outside of it.
#accountRetirement #shrinkNostr?
#nevent1q…e2n5

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-17 01:33:29 CET

- reply

@nprofile…jgy8, @nprofile…fzvp, @nprofile…m55g and last but nost least @nprofile…8ltw (many thanks for your contribution mate)

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

2026-01-03 20:49:45 CET

- reply

Thanks, Oberon. I’m unfortunately sort of done with all the "getting used to" after more than a year around here. There isn’t much left on NIP-01 once I filter out low quality posts (though I’ll miss Japanese Nostr, some of the Nostr devs, and a few artsy folks). That said, there are some brave, persistent people trying to raise the bar on Nostr, buried beneath mountains of BTC L2 marketing posts, bots, GAB-like stuff, etc. Unfortunately, I don’t see this changing despite their valiant efforts with hashtags, custom relays, and so on. Still, have a look at my follow list, there are some gem npubs there, even though a lot of them have also quit Nostr.

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-12-29 15:56:20 CET

- reply

Thanks for talking some sense and baiting some of the bad apples on Nostr to out themselves, @nprofile…6u4e. Nostr content is getting so tiresome...
Fun fact: while you were taking a break, I got some heated DMs basically calling me a hypocrite for collaborating with you and Bitvora while calling this shit out on Nostr. Apparently, they took you for one of the racist / North American MAGA / authoritarian-dressed-as-libertarian sheep on Nostr. And Bitvora for one of the crappy, spammy Lightning service providers on Nostr (after I blocked a couple from spamming the relays I’m running and returned a few of their bribery attempts).
For the folks who need a reason for me to volunteer my time (why would anyone need a reason to maintain good software?), that’s why. Don’t take a good man, a builder, a second-generation Canadian, for one of the low-IQ, xenophobic racists loitering here.
Signed: a Brazilian-born, UK citizen who has contributed more to this country in the past ten years than all of the Tommy Robinson followers on Nostr combined. I never claimed any benefits, not even during unemployment (and yes, things got pretty rough for a while). I built two businesses from the ground up, volunteered quite a bit, and was subjected to the 60% UK tax trap for several years while paying extra fees like the NHS surcharge. Tax-wise, I am sustaining an average of at least half a dozen of Tommy Robinson’s “patriots” on the dole while they are busy coming to London to riot and paint roundabouts red. The only thing I have to say to the "patriots" out there is... Piss off! Stop complaining about the immigrants putting food on your table and get good. Real patriots should, you know, do something for their country other than seeding hate and trying to start riots.
You folks voted for Brexit. You folks did nothing while the corrupt politicians you voted for sold out. You folks let private equity take control of the country, including real estate. You are the ones about to elect Farage and swallow Musk’s fascist rhetoric of “violence is coming for you” while letting the US and Big Tech aristocracies weaken Europe and ruin our way of life. I have nothing to do with the UK’s decline. You do. Stop blaming immigrants for the consequences of your choices. Also, be careful what you wish for. Unlike you, I have real mobility (hint: moving abroad is nowhere near as easy as you think), so please take some responsibility and stop destroying the country that I love and that you are trapped in. Take some responsibility before it is too late.
PS: As a very white person (yes, there are lots of people of European descent in Brazil, mostly children and grandchildren of European immigrants fleeing their countries during difficult times, so do remember that tables turn), I can say that “Arabs”, “Asian”, and “Brown” people are doing very well, thank you. In fact, most British “patriots” I know would move to places like Dubai and Qatar without a second glance if they had the opportunity to.

2025-11-11 16:34:18 CET

- reply

Dor some reason on Amethyst I only saw your own answer after I commented, lol. jq is love, jq is life.

2025-11-11 16:33:19 CET

- reply

No built-in negative filtering mechanism that I know of. Maybe pipe it through jq (warning, untested):
nak req relay.damus.io | jq -c 'select(.kind != 3)'

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-11-06 19:32:07 CET

- reply

That’s… a lot lower than I would expect, at least considering Munich’s cost of living the last time I checked. Plus, having to buy or rent your own kitchen, pay three months’ rent upfront, etc. Sounds like you’re as screwed as we are here in the UK. Actually, as bad as things are here, if you’re good you can get a better deal in places like Glasgow or Leeds, which have a much lower cost of living than Munich.
Well, like anything, I’m sure salaries follow a power law there. I have some former colleagues contracting for Siemens, big banks in Frankfurt, etc., at around €800+ a day. And they aren’t working in front office or boutique hedge funds, so I’m sure that while averages are lower, the opportunity to increase earnings is there (even in this awful job market, where so many companies are outsourcing like there’s no tomorrow).
Apologies anyway, I don’t mean to pry or make this all about earnings and fiat jobs or contracting. Earning a bunch of money isn’t proof of hardwork or intelectual capacity. My point still stands though: whatever you get paid outside of Nostr, that’s your real opportunity cost. At the moment, very few people on Nostr get anywhere near their opportunity cost. In fact, for me at least, Nostr is an endless money sink and a totally unsustainable passion project. It works well when I’m chronically unemployed burning through my savings… otherwise... folks need to pay their bills.

2025-10-26 23:46:45 CET

- reply

Will have a look, thank you.

2025-10-25 16:02:41 CEST

- reply

This one is already pretty "mainstream", or as close to it as a CLI transfer tool generally gets (almost 32k stars on GitHub; I’m not sure the whole Nostr ecosystem combined gets that much attention).
But fair point regardless, especially for folks using public relays. Just like in Nostr, sending some money to public relay runners (like @nprofile…6u4e, @nprofile…dx2g, @nprofile…nggv, @nprofile…hfq7, etc.) is a good way to keep their respective public relays alive.
Likewise, sending some $$$ to FOSS developers is the best way to guarantee they actually get some development time.
This is something that folks (even those who say they’re all about "value for value" like here on Nostr) are really bad at. If only users knew how expensive it is to develop and run this sort of thing, they’d probably pool together an annual budget to split among the FOSS devs building the tools they rely on.

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-23 02:39:49 CEST

- reply

GitHub is quickly becoming unusable, just like LinkedIn and everything else Microsoft has acquired. I really hope Nostr's adoption of GRASP / NIP-34 gains momentum. My Forgejo instance has everything I need really. I'm slowly but surely moving away from GitHub.

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 16:29:33 CEST

Who is the developer (or developers) behind @nprofile…8zqj? Is it open source? If so, where can I find the code?
#asknostr

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 23:19:23 CEST

- reply

Run your own relay, your own Blossom server (or NIP-96, or whatever). Run your client locally. Block all Cloudflare IP ranges across the board and be happy.
Yes, you will break several clients. Yes, folks can still broadcast or mirror your stuff to one of the gazillion Cloudflare-enabled relays and media servers out there. But overall, there’s not much anyone can do to fully "opt out" of Cloudflare on the public internet.

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 21:26:08 CEST

- reply

I couldn't see messages from the other npub notes as well before you and Carlos replked (this one is clearly human, so the company behind the bots is at least monitoring mentions which is already better than a lot of the other "welcome to Nostr" stuff out there). Ultimately its up to each relay operator to decide what is useful or not. The only reason I even saw the bot messages is due to Amethyst new Outbox model. I personally find all and any of those welcome bots, wallet detection bots, auto zapping promo bots and variations of the above a nuisance. I try my best to curate my own Nostr feed for human content. But I'm not trying to tell any of you how to run your relays other than commutating that to me they are a nuisance.

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-20 00:04:41 CEST

- reply

Hey Mike,
Thanks for coming back on this one. Just so I’m clear on what we’re discussing, given the sophisticated heuristics here: are you talking about choosing “default” Outbox relays for new keys? Or is Gossip ignoring write relays from users that don’t match the above criteria? For example, if I manually set a write relay that has a broken NIP-11, will Gossip respect my choice, or skip the relay I configured myself when I publish my own events?
Either way, despite your comment below about not wanting shared blacklists, it feels like every client going through this process to compute lists of dead relays is a lot of duplicated work and wasted effort. I understand the value of having stricter criteria for suggesting default relays to new npubs and potential fallbacks, but I wouldn’t expect every client (or relays needing to calculate WoT and other advanced functionality) to handle all of this aggregate data collection and processing.
IMO a shared blacklist (optional for clients to use, and that they are of course free tk verify) seems like a more pragmatic solution.

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-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-08-01 17:15:52 CEST

- reply

I noticed. Endorsing content you like and people you trust is a powerful tool. Your followers doing this (interacting with your main profile) is the reason your content reaches me, and why we have all sorts of interactions despite not following each other directly.
They stop following you, your content stops reaching my feed (and vice-versa unless you are using one of the indirect ways to keep up with me mentioned above).
There has to be a way to solve Nostr’s cultural issue of “degrees of separation and endorsement from Jack / Odell / Derek / Lyn / Will, etc.” as a measure visibity without burning down the social graph and scorching the earth behind us.
My hypothesis is that we need a culture of more intentional following like what you're advocating for, but with proper ownertrust-style tools. I've asked around and a lot of people want to “follow that one person who produces crappy content we’re all embarrassed by, but we still love them regardless”. So kind 3 is better than nothing but not sufficient for WoT.
My main problem is how to bake in that intentionality in a way that’s accessible and fun instead of recreating a dumbed-down version of the PGP Web of Trust experience. It’s definitely an interesting research problem, one I don't have an immediate answer for, unfortunately.

2025-08-01 16:15:51 CEST

- reply

I'm really not interested in your data specifically as what happens if everyone follows you down this path (we’ve had this conversation before and agreed to disagree on this inr). But IMO, just to entertain this argument, we can take this line of thought to the extreme.
I have no illusion that AES-256 encryption is truly private against folks with the right resources. But going down that path, are you 100% sure that a relay running on your mobile is private?
Take this to the extreme and we’ll end up with non-social, 100% offline, share-nothing "social media".
At some point, you have to decide on features vs threat model. I’m happy to expose my social graph if it helps other folks discover good content on Nostr.

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-26 12:35:03 CEST

- reply

I can't zap you

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: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-15 10:01:57 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