Last Notes
I was too to write one. But not for now. I need time.
Sounds like you got the basics going already. Yeah, having settings for nsec, bunker tokens and in the future maybe lighting + NWC would be great. I'll have a look and play around with it. Thanks!
This one is the closest thing AFAIK https://dvmcp.fun/s/nostr-mcp-server you can test it straight there. I'm also thinking in creating one with better ux, and with the ability to set your nostr connect string so it can sign things. I don't have too much time for this rn, but happy to discuss and design if someone is up for the challenge
Truthfully I didn't have to do much at all! Were pretty small right now, so just keeping any eye on our status pages.
It did seem like the world was melting down for a bit there XD
Differentations by relay(s) 💯
NIP-29 is really really good. I like it. Somebody should spinup a reddit style thing on it.
The "clean feed" issue is actually a pretty hard one to solve though. I don't want algorithms (with a passion). But then again, even standard Nostr content (Libertarian / bitcoiner maximalist stuff) will send a lot of folks running at first glance. Long before they even encounter sex workers, MGTOW, or the truly toxic stuff. And likely before they can find the cats, dogs, photography and artsy stuff. A typical user might install something like Primal, scroll for 30 seconds, label it "crypto-bro tech", and walk away.
Same goes for ActivityPub, by the way. You've got old German naturalists, "legalise weed" folks, Pastafarians, etc... All fine with me, but many people wouldn't consider that a "clean" experience. And that’s before they run into the actually problematic stuff on there.
Even on heavily moderated networks like Bluesky, people are struggling with this. The main problem is that a "clean feed" is subjective.
I think NIP-29 sort of has the right idea. It reminds me of early social media, like Orkut. We need to have easy ways to allow for bubbles to form organically while still preserving Nostr’s decentralised nature for those willing to venture outside their shells a bit.
Tbh most people don't care as long as they see a clean feed. If they do see problems that's when we can educate them, also I really like amethysts "5 people in your contact list have reported this post" feature.
I agree. Same story here. I self-hosted Mastodon for five years. Now I'm paying for masto.host and also running my own GoToSocial instance. Mastodon itself is a pain, one viral post is enough to make the Ruby and Elasticsearch processes chew through 8GB of RAM. Plus Masto version migrations can be painful.
GoToSocial isn’t bad though. I may even get rid of full-blown Mastodon at some point, as there’s not much I miss when using GoToSocial. There are also a few other Mastodon-compatible ActivityPub servers at different stages of maturity, each with different trade-offs, just like Nostr.
That said, Nostr certainly has the edge here. It’s kinda amazing that I can run Haven + Nosotros with all the bells and whistles on such minimal resources. It’s a much more feature-rich combo than something like GoToSocial for sure, and it doesn’t require 8GB+ of memory like Mastodon, or a full datacentre, a nuclear reactor, and privileged access to proprietary software like Bluesky 🤣.
I agree. Same story here . I self-hosted Mastodon for five years. Now I'm paying for masto.host and also running my own GoToSocial instance. Mastodon itself is a pain, one viral post is enough to make the Ruby and Elasticsearch processes chew through 8GB of RAM. Plus Masto version migrations can ve painful.
GoToSocial isn’t bad though. I may even get rid of full-blown Mastodon at some point, as there’s not much I miss when using GoToSocial. There are also a few other Mastodon-compatible ActivityPub servers at different stages of maturity, each with different trade-offs, just like Nostr.
That said, Nostr certainly has the edge here. It’s kinda amazing that I can run Haven + Nosotros with all the bells and whistles on such minimal resources. It’s a much more feature-rich combo than something like GoToSocial for sure, and it doesn’t require 8GB+ of memory like Mastodon, or a full datacentre, a nuclear reactor, and privileged access to proprietary software like Bluesky 🤣.
I’ve run my own Mastodon instance. And do run some other activitypub stuff too still.
It’s a pain in the ass to host / maintain. The biggest issue it does not scale at all and when you start to interact your infrastructure does get DDOSed when your engagement grows with the network.
You pretty much nailed it. Thanks for sharing knowledge and looking after new users 🙂. One of my gazillion side quests is breaking down the docs a bit. While overindexing on documentation is a good thing, having everything in a single README can be a bit overwhelming.
Also, Haven is currently gaining a ton of undocumented secondary features (e.g. support for backups and Blossom on dozens of S3-compatible object storages). Mea culpa.
I'm a bit busy with some PGP-related side quests, but breaking down the docs and writing a Quick Start guide a la:
> “Download the latest binary here. Replace your npub here, your domain there, run `./haven` or `haven.exe` with `--import`, wait, restart, profit!”
is otherwise at the top of my priority list.
Oh, I thought I'm looking that realized this. Thanks a lot, and same. Onward. 🫡
It does cost us money, but we cover that with the Geyser donations we receive for Alexandria.
I just always look straight at global, and Cloudfodder is extremely attentive, so that works out well. Especially, as we're in opposite time zones.
NFDB is my own relay software, only for internal use at Nostr.land though.
I have shipped *a lot* of features over the last few months to Nostr.land, while many other paid relays are stagnant.
I am comparing relays based off of my experience operating strfry at scale, and other applications that I managed myself using MongoDB. Compared to current NFDB, it is simply not possible to get the same performance or flexibility with other solutions.
> Speed matters when user feels it!
> You need to satisfy user, not fight with milliseconds on low level codes to show off for marketing.
Sure, until you realize that when your relay is used at larger scale for a few years, then it crumbles. I have ran MongoDB in several production applications and it has always underperformed by an order of magnitude or more compared to Postgres and FDB *on the same hardware*.
Request latencies reached hundreds of ms at times. So yes, the user will notice.
> How people can confirm your NFDB thing is really faster?
I will be publishing a benchmark when I have finished more important priorities.
> Also, Manageability and Scalability is important. How much you can scale? Is your software able to scale at all?
More details on this, NFDB is built on FoundationDB. It can scale to 100TB+ clusters easily, and certain parts of NFDB could be modified if higher was really needed.
The broadcast system runs on Apache Pulsar.
Alright... Here's what I changed:
OWNER_NPUB - This should obviously be changed to the npub you will be using Haven with.
RELAY_URL - This should be the domain where the relay will be accessible.
Leave the rest of the settings in this top section of the .env as they are unless you have a specific reason to change them and pop down to the Private Relay Settings.
PRIVATE_RELAY_NAME - You can name it whatever you like, but probably don't want to leave it as "utxo's private relay." Each of the other sections allow you to change their name, too.
PRIVATE_RELAY_NPUB - This should be the npub you plan to use the relay with. The private relay will only accept notes authored by that npub. Same applies for all the other sections below that allow you to set the relay npub.
PRIVATE_RELAY_DESCRIPTION - You can leave this as is or change it as you see fit. It just gives those who check the relay description document an idea of what the relay is for.
PRIVATE_RELAY_ICON - Slap in a URL for an icon for your relay. Think of it like your relay's profile picture. Keep it small. You can even have a separate icon for each of Haven's relays, if you want.
I haven't changed anything in the Private Relay Rate Limiters section.
Your "Chat" relay is used for receiving DMs. Apart from the fields similar to the Private relay setup, you may want to adjust the WoT depth, how often the WoT is refreshed, or the minimum number of followers. These settings dictate who can post messages to your DM inbox, so you don't get a bunch of spam DMs. But, if you want to see DMs from people outside of your WoT, you may want to make these less strict by reducing the CHAT_RELAY_MINIMUM_FOLLOWERS to 0, but know that you will start getting spam DMs, too.
Make similar updates as you did in the Private Relay section to the Outbox and Inbox sections, too.
Your Import Settings may also need to have the date updated, depending on when you joined Nostr. Haven will import your notes from other relays from that date to present, based on the relays you instruct it to pull from in the relays_import.json document.
Finally, you may need to add some values in the AWS Backup Settings, if you are having Haven backed up to AWS.
The next document you will want to make sure has all the relays listed that you want to pull from is the relays_import.json. Make sure it is pulling from any and all relays you can remember writing to in the past. It's already including relay.nostr.band, which is an aggregator, so it should be able to find most of your notes, regardless.
And to round it all out, you'll want to edit the relays_blastr.json to include any relays you want your public notes mirrored to. This will only be notes that you are writing to your Haven outbox relay. The default relays are pretty decent, but you may want to make some adjustments. Note, you should not choose any relays that require AUTH for write access, as Haven will be unable to sign their AUTH requests.
Maybe @npub1utx…50e8 and/or @npub1a6w…0tyc can review the above to ensure I haven't given any bad advice. 😂
Word, you are fast. Thank you, I'll play with it this weekend :)
“How much you can scale? Is your software able to scale at all?” Currently to about 50x of the current state of Nostr, without any changes.
Don’t waste your time with semisol. The only way he knows how to market anything he builds is by criticizing others. It’s pretty transparent and most people know it at this point.
Keep building - the rest of us appreciate you.
Consider that we are open source as well.
How people can confirm your NFDB thing is really faster?
Open Source code + fully detailed benchmark is needed.
Import and export is also supported in Immortal software and will be running on next version.
Speed matters when user feels it!
You need to satisfy user, not fight with milliseconds on low level codes to show off for marketing.
Also, Manageability and Scalability is important. How much you can scale? Is your software able to scale at all? Sorry I don't know since it's closed source.
And the last thing, @nprofile…eph4's nostr wine service is well documented and super reliable. They are also super professional with users and everyone. Which convinced me to subscribe to their relay even when I had Jellyfish up and running.
The answer is obviously nostr.land. :)
While @npub1hu4…c46u has their own software that’s it. It runs on MongoDB which is known to be very slow, and they have no value proposition except paid relay.
Wine is a set of duct taped relays running on strfry, and you’d need 4 relay connections to only somewhat replicate the functionality of Nostr.land.
And Nostr.land offers convenient import/export and runs NFDB.
In this transitional world we live in where some clients support the outbox model and some don't, I have come to the following setup:
Kind 10002
- Write to your own Haven outbox relay, and set it up to blast to the 10 most popular public relays.
- Write to and read from a paid relay of your choice. I'll let @npub18kz…x5sz, @npub1226…grkj, and @npub1h49…9kay duke it out for which one you should choose.
- Read from your own WoT relay (set up to aggregate notes from your WoT) and your Haven inbox relay.
Kind 3 - For those clients that support using it to supplement your inbox/outbox setup.
- Read from a couple other WoT relays and aggregators that might fill in some gaps missing in your inbox relays.
- Write to... nothing additional should be needed. Your outbox relays should suffice.
If you don't have your own Haven relay, then some adjustments need to be made. But Haven really is helpful to have. THANK YOU @npub1utx…50e8 and @npub1a6w…0tyc!
I added some functionality related to repository deletion:
- show red banner and notices when on a repository page that has been deleted
- add delete button if there are less than 5 issues or PRs
- hide deleted repositories form search results and profile page
I was reading these docs evening too.
https://github.com/fairpm/fair-protocol/blob/main/docs/start-here.md
To get inspired.
Its been on my list to look into @nprofile…xfvf's nostr package management project.
Got it. What I'm trying to say is, maybe you have already created one in the past?
I'm asking because Coracle has a "Lists created by people in your network" feature displaying a kind 30000 list created by you.
https://haven.accioly.social/08ff3eee6b5cc0025951feda9fabe2227c1b2b31e026a8d5184197a5fc3ab868.png
I'm not sure if this is compatible with Amethyst, but it looks like a custom following list. @nprofile…pyug, are Kind 30000 Follow sets supported on Amethyst?
https://njump.me/naddr1qvzqqqr4xqpzprva9dmexrh9fmp7gma0waxa6pqahd8y4g66637qykyy52rd6e06qq25kjr6d9pkx6zrg3552u2f8ph5u3e4xp3nxwt94g8
My general follows list on amethyst is good, but some of my follows get lost in the shuffle, so want to make a favorites list.
I use amethyst, and just found out that nostrudel has a list feature that i can use for this. Just wondered if it could be built into amethyst. Didnt know about listr either, i'm behind.
Aren't you using your "Favourites to follow" list?
#naddr1qq…ahwd
Out of curiosity, what client wereyou using for it (Coracle maybe?) And what could be improved about it?
Just looked at their FAQ. Yeah, whatever they are doing works well for eventually consistent sync, not for potentially time critical notifications:
Background sync
Apple iOS restricts apps from running continuously in the background, but apps can run for short times sporadically. Möbius Sync uses various methods to invoke background behaviour. The minimum interval between quick syncs and power syncs can be configured under Settings, but iOS schedules background activity in an adaptive manner that is not predicatable and sometimes counter-intuitive. It may take 24 hours to start to sync but you can expect a total of 1-2h of sync activity per day once stable.
I didnt know that. Bad example from a technical feasibility PoV then. The point about approvals is still true though.
Note to self: Avoid Apple.
I agree. In the end, reviewers can allow anything to happen if you have a good reason. :)
https://i.nostr.build/NvEImV8Kw8Zj3sGh.jpg
Yep. Pokey has a lot of trouble staying alive already. If we have too many of these background apps, the OS will just start killing them randomly.
Even with background workers? I'm trying to design something for normies without pokey, obviouspy if they have pokey installed that would be preferable. Is there a way to detect if pokey is installed?
If you do this, I would try to build an external reusable component for iOS. That way you will "solve" the problem for other clients as well.
IMO, despite all of the limitations mentioned above, I've become a fan of Pokey. To the point that I've disabled most of 0xChat notifications that use the push model.
It isn't perfect by any means, especially given what you want to do that involves decrypting NIP-17 with random keys. But it works well enough. IMO, better than a lot of clients with full blown push servers, custom notification relays, etc.
No, please don't do that. If all apps are running in the background, there won't be enough battery. Pokey should do that for you and pass the event to your app for display.
I guess I could also just imitate pokey and do the same background processing in Flotilla directly. But the limitations just seem so severe. From perplexity:
- Android allows background services, but recent OS versions (Android 8/Oreo and above) impose strict limits on background processing to save battery life.
- Foreground services can run persistently but must display a notification, which is not ideal for most user experiences.
- Periodic background work can be scheduled using WorkManager, but the frequency is limited and not real-time.
I've been using pokey since day 1. It uses almost no battery, it's always <1% in my battery stats. Essential Android Nostr software.
Yeah, I agree, there are trade-offs here. UX itself isn't too bad (although clients do lose a bit of flexibility for sure). But given the alternative is to trustanother third-party, I still prefer the pull model.
Folks running their own relays could potentially run an "aggregator" + push server. I already though about building something like this, but I don't see many users setting that up, nor clients willing to support this to be honest. Maybe in the future, side quest n 788.
As a user, battery use is negligible.
I read pokey's readme and played around with it, it does look like a background process. Which is great for user security, but not so much for battery use, multi-device, or UX simplicity.
Add iOS to my list above 😅. In theory, you could also add the background process to Coracle, but I like the idea of doing this externally to clients to avoid duplicated work.
I've already tagged Koala above, as he's much more knowledgeable about all of this than I am. But as far as I understand, it's" just" a background process (easier said than done, given how many kinds need to be supported and fetched from different relays in different ways, including things signed with random keys and non obvious filters) plus Android’s Intent system magic to launch other Nostr apps. Something like Pokey should, in theory, be doable on iOS.
All of this is a potential problem with any app, which is why I've never liked how Nostr keys work. We should be able to generate sub keys or something for apps. Using a separate key for everything dampens the appeal for me. And it still doesn't solve getting rekt on a particular app.
A hardware signer at least would be nice, but I'm guessing that UX would suck for the social media case. Maybe using it to generate or destroy sub keys?
It also may be unapparent what is vibed and what isn't. Even non-vibed may have shit security. That's why I favor a deeper solution. Maybe it isn't possible. I have no idea.
I think @nprofile…l3q3 and I have notes discussing this somewhere.
Well, I need this to work on iOS as well. But I'm also a little in the dark about how pokey works (I know next to nothing about android development). Is there a server component, or does pokey just run in the background all the time?
This is very good advice.
#nevent1q…4zn7
> O outbox não permite isso. Caso contrário, vamos criar mais problemas para os outros apps que não esperam esse tipo de distinção
Mas o Amethyst já está fazendo isso hoje sem nem dar a opção de corririgir correto? E.g., quando eu posto uma nota kind 1 de alguma maneira ela também vai parar no meu Inbox, relay de notas privadas, relays de DM, etc. Ou isso também já foi corrigido no master / só não lançado ainda.
> Sinceramente, meio que estou decepcionado com o baixissimo impacto desses apelos ao usuário. Usuário nenhum configura corretamente os relays. Talvez precisamos de uma estratégia diferente onde os usuários nem mexem com isso. A app simplesmente sobrescreve tudo e corrige os problemas automaticamente.
Eu entendo a frustração... Mas de cadinho em cadinho vamos melhorando. Autosettings é uma excelente ideia. Mas acho que dificilmente será implementando de maneira adequada na maioria dos clientes. E se for um serviço independente, as únicas pessoas que vão usar provavelmente não precisariam 🤣. Os usuários sempre vão precisar de alguma educação sobre o assunto para usar uma rede social descentralisada com conceitos mais avançados como O Nostr... E os devs... Também 🫠
> > novos relays adicionados ao Kind 10050 só escrevem e leem eventos NIP-17,
> Isso já está corrigido no master branch.
Excelente. O Amethyst é um dos poucos clientes não especialidados em mensagens que suporta NIP-17 direito. Parar de mandar minhas mensagens para relays públicos sem AUTH já é um passo excelente na direção correta.
> O problema é a migração errada. Primal, nostrudel e outros colocaram todos os relays do kind 3 no outbox e agora todo mundo tem 20 relays na lista que deveria ter só 3. Agora os clientes precisam lidar com 20 relays ou correr o risco de não encontra os posts se escolherem só os 3 primeiros ou se randomizar 3 relays da lista.
Eu entendo bem novamente. O Haven tem o mesmo problema para construir WoTs. É bem difícil evoluir algo quando todo mundo está destruindo as listas / sets, etc. De novo, alguém tem que começar o processo de educação e forçar os outros devs a correrem atrás. E.g., um ano atrás eu estava teimando com o utxo sobre remover suporte para kind 4 do Haven e o double down em Blossom (e apenas Blossom). Mas agoras vivemos em um mundo com Primal com suporte e Blossom e até mesmo mirroring. DM-17 infelizmente ainda não prgou... Mas se não fosse o Nostrudel e Amethyst forçando a barra nessa direção, nem a evolução que conquistamos teria acontecido.
> Adicione as setinhas mesmo nos relays de Inbox, Outbox, DMs etc.
Não. O outbox não permite isso. Caso contrário, vamos criar mais problemas para os outros apps que não esperam esse tipo de distinção
> Faça mais algumas maratonas ajudando usuários a configurarem relays "corretamente"
Sinceramente, meio que estou decepcionado com o baixissimo impacto desses apelos ao usuário. Usuário nenhum configura corretamente os relays. Talvez precisamos de uma estratégia diferente onde os usuários nem mexem com isso. A app simplesmente sobrescreve tudo e corrige os problemas automaticamente.
> novos relays adicionados ao Kind 10050 só escrevem e leem eventos NIP-17,
Isso já está corrigido no master branch.
> Mas para dar certo grandes como o Amethyst, Damus, Primal, etc tem que começar esse processo de migração "gentil" dos usuários.
O problema é a migração errada. Primal, nostrudel e outros colocaram todos os relays do kind 3 no outbox e agora todo mundo tem 20 relays na lista que deveria ter só 3. Agora os clientes precisam lidar com 20 relays ou correr o risco de não encontra os posts se escolherem só os 3 primeiros ou se randomizar 3 relays da lista.
Eu entendo o trade-off e a dificuldade de evoluir sem desagradar usuários e quebrar o que já está lá (o Haven está para completar um ano e já estou lidando com situações assim. Vou precisar lançar uma v2 não backwards compatible em breve). Eu sei que o que estou falando provavelmente não consid34w uma série de constraints arquiteturais do próprio Amethyst, mas na sua pele eu atacaria isso com o famoso exercício do "carpaccio de elefante".
Passo 1: Faça todas as milhares de setinhas do Amethyst para read e write funcionarem. Adicione as setinhas mesmo nos relays de Inbox, Outbox, DMs etc. Nesse ponto usuários como eu podem usar as opções de configuração para parar o self-spamming nos próprios Relays deles 🤣. Ah.. adicione setinhas e opções de tempo para salvar drafts também, pois drafts são uma das coisas que estão spammeando infinitamente os relays.
Passo 2: Não mexa nas configurações dos usuário atuais por enquanto (i.e. a galera que está mijando fora do pinico em todos os relays que existem vai continuar mijando fora do pinico, bem como lendo uma firehose com todos os eventos do Nostr e mais alguns). Faça mais algumas maratonas ajudando usuários a configurarem relays "corretamente". Mostrando a diferença que isso faz em performance, bandwidth, bateria, etc. Você já fez isso várias vezes no passado, mas é um trabalho contínuo de educação.
Passo 3: Mude o código para que novos relays específicos (E.g., inboxes e outboxes adicionados kind 10002, DM relays no kind 10050, etc) já entrem com as "setinhas" corretas, e.g., novos relays adicionados ao Kind 10050 só escrevem e leem eventos NIP-17, etc. Quem quiser o comportamento antigo pode ir lá, adicionar o mesmo relay na seção de relays gerais e clicar em todas as setinhas que quiser.
Passo 4: Avise para as pessoas que daqui a 6 meses ou um 1 ano ou sei lá quando você vai remover as setinhas e a seção de relays gerais. Espero o dobro do tempo e aí sim faça usso.
O que eu quero dizer é, se clientes como o Amethyst empurrarem os novos padrões aos poucos, isso não vai desagradar os usuários. E com o tempo, conforme a galera for mexendo nas configurações de relays, criando novas chaves, etc todo mundo vai migrando para os novos padrões. Aos poucos essa diferença entre Outbox model e companhia vs ler e escrever de / para todos os relays do Universo vai diminuindo.
Mas para dar certo grandes como o Amethyst, Damus, Primal, etc tem que começar esse processo de migração "gentil" dos usuários. O Amethyst, apesar da entropia, ainda é um dos clientes mais ágeis e maleaveis entre os grandes. Se você não sinalizar a mudança eu duvido que os outros corram atrás.
Dito isso, entendo que mesmo nesse modelo de fatias finas, alguma dor de migração será necessária. Se não vamos ficar nesse loop de que não dá para ler/escrever nos relays corretos pois os clientes não estão lendo/escrevendo dos relays corretos para sempre.
Eu entendo o trade-off e a dificuldade de evoluir sem desagradar usuários e quebrar o que já está lá (o Haven está para completar um ano e já estou lidando com situações assim. Vou precisar lançar uma v2 não backwards compatible em breve). Eu sei que o que estou falando provavelmente pula uma série de constraints arquiteturais do próprio Amethyst, mas na sua pele eu atacaria isso com o famoso exercício do "carpacho de elefante".
Passo 1: Faça todas as milhares de setinhas do Amethyst para read e write funcionarem. Adicione as setinhas mesmo nos relays de Inbox, Outbox, DMs etc. Nesse ponto usuários como eu podem usar as opções de configuração para parar o self-spamming nos próprios Relays deles 🤣. Ah.. adicione setinhas e opções de tempo para salvar drafts também, pois drafts são uma das coisas que estão spammeando infinitamente os relays.
Passo 2: Não mexa nas configurações dos usuário atuais por enquanto (i.e. a galera que está mijando fora do pinico em todos os relays que existem vai continuar mijando fora do pinico, bem como lendo uma firehose com todos os eventos do Nostr e mais alguns). Faça mais algumas maratonas ajudando usuários a configurarem relays "corretamente". Mostrando a diferença que isso faz em performance, bandwidth, bateria, etc. Você já fez isso várias vezes no passado, mas é um trabalho contínuo de educação.
Passo 3: Mude o código para que novos relays específicos (E.g., inboxes e outboxes adicionados kind 10002, DM relays no kind 10050, etc) já entrem com as "setinhas" corretas, e.g., novos relays adicionados ao Kind 10050 só escrevem e leem eventos NIP-17, etc. Quem quiser o comportamento antigo pode ir lá, adicionar o mesmo relay na seção de relays gerais e clicar em todas as setinhas que quiser.
Passo 4: Avise para as pessoas que daqui a 6 meses ou um 1 ano ou sei lá quando você vai remover as setinhas e a seção de relays gerais. Espero o dobro do tempo e aí sim faça usso.
O que eu quero dizer é, se clientes como o Amethyst empurrarem os novos padrões aos poucos, isso não vai desagradar os usuários. E com o tempo, conforme a galera for mexendo nas configurações de relays, criando novas chaves, etc todo mundo vai migrando para os novos padrões. Aos poucos essa diferença entre Outbox model e companhia vs ler e escrever de / para todos os relays do Universo vai diminuindo.
Mas para dar certo grandes como o Amethyst, Damus, Primal, etc tem que começar esse processo de migração "gentil" dos usuários. O Amethyst, apesar da entropia, ainda é um dos clientes mais ágeis e maleaveis entre os grandes. Se você não sinalizar a mudança eu duvido que os outros corram atrás.
Dito isso, entendo que mesmo nesse modelo de fatias finas, alguma dor de migração será necessária. Se não vamos ficar nesse loop de que não dá para ler/escrever nos relays corretos pois os clientes não estão lendo/escrevendo dos relays corretos para sempre.
#GM Fren 🌞 have an amazing day today https://youtu.be/wqCz3-v3PHA
#GM Fren 🌞 have an amazing day today https://youtu.be/wqCz3-v3PHA
Poisé, uma das coisas que eu estou tentando refinar com outbox, mas tah difícil. O Amethyst sempre mostra muito mais posts do que todos os outros clientes. Se eu usar o ditto, primal ou coracle por exemplo, eu perco 10-20% do meu feed.
Isso acontence pq os posts estão nos relays errados. O blast do Amethyst para download garante que o feed seja o mais completo, mas ao custo do uso do plano de dados. O blast the upload tenta fazer o post aparecer nas outras apps, mas ainda não é suficiente.
Além dr saber antecipadamente que não é um nativo.
Eu só não consigo perceber a diferença nos que praticamente nem são brasileiros mais, ex:vc, o fiatjaf e outros que não moram no Brasil.
Mas enfim, talvez vc tenha razão e isso seja o futuro e realmente funcione bem. Com certeza quebraria fronteiras e seria muito bom. Eu acredito que tradução instantânea em video mais interessante do que em texto, pois no vídeo vc consegue ver as expressões.
Para o cérebro a coisa toda realmente demanda um certo nível de plasticidade que eu não tenho mais. Para ser sincero eu já mal acompanha o que está acontecendo no Brasil em geral (mesmo tendo família ainda morando no país). Quanto mais entender o contexto das últimas tendências Ancap, xpto que rolam aqui no Nostr.
De uma maneira ou de outra, nessa daqui eu não vou culpar a tecnologia. Se existe uma maneira fácil de desligar a feature, acho que o Amethyst está fazendo a coisa certa (nesse ponto, tem várias coisas em que o Amethyst é uma merda e a codebase já chegou naquele ponto de entropia em que fixes requerem mudanças estruturais mais radicais).
O Jumble e Nosotros são ambos muito bacanas e eu uso eles no Desktop. Mas tem muita coisa em que o Amethyst ainda é a melhor (ou a única alternativa)... Apesar de spammar meus relays como se não tivesse amanhã. Minha principal reclamação principal sobre o Amethyst continua sendo a mesma. Em relação a simplesmente escrever eventos em relays, Amethyst parece alguns homens tentando usar o banheiro. O Amethyst espalha eventos para todos os lados, menos para onde eles deveriam ir 🤣 (sem respespeito aos devs by the way, enquanto desisti de insistir no assunto, entendo bem o porquê das coisas estarem como estão apesar das melhores intenções de todos os envolvidos).
Mas isso que estou falando. Para aumentar o alcance, muitos brasileiros no Nostr só postam em inglês. Vc nem sabe que são brasileiros. A lingua do post não é um bom indicador da cultura da pessoa. A maioria acha que eles são americanos e vem falar de detalhes de cultura americana que o autor nem sabia do que se tratava.
Quando se sabe que o texto é traduzido, existe muito mais tolerância na conversa.
Sim, mas meu problema não é esse. A questão é a pessoa saber se quem está do outro lado é nativo ou não. Uma pessoa geralmente não conversa do mesmo jeito com um não nativo, pois ela entende que muitas nuances não seriam entendidas em uma conversa traduzida. Meu ponto de discordância é só na questão de saber se aquela conversa tem origem em tradução ou não.
Não tem nada a ver com a escolha da linguagem. Por exemplo, grande parte do Nostr em ingles não são nativos do inglês. Eles postam em ingles com a cultura da linguagem de origem. Vc já está lendo algo traduzido o tempo todo, muitas vezes mal traduzido pq o autor não sabe se expressar tao bem em ingles. Para a grande maioria destas pessoas, é melhor postar na liguagem de origem e deixar o tradutor do destino traduzir do que postar já traduzido.
Já é complicado conversando com pessoas nativas, expressar em texto o que vc quis dizer, a forma a emoção, imagina usando tradução?
Eu não posso conversar da mesma forma com um estrangeiro em relação a um nativo. Talvez conversas super técnicas ajude, mas nesse caso, tradução por demanda eu vejo mais sentido. Mas para conversas aleatórias tradução automática entre pessoas com diferentes culturas, acho complicado e penso que causaria bastante ruídos.
Pois existem barreiras culturais que em uma conversa, precisamos separar.
Dá para desabilitar por linguagem ou basta usar o flavor do fdroid, que não tem traduções. Vc nunca vai saber se está falando com nativo ou não.
Acho que dá para desabilitar sim, mas migrei em definitivo para o Jumble, rs.
Pode ser que eu esteja errado mesmo e isso seja o futuro da comunicação sem barreiras. Mas atualmente eu gosto de saber se estou conversando com um nativo ou não.
Eu acho que dá para desabilitar não dá? Nessa daí ru vou concordar com o Vitor porém. Eu sou bem menos bullish sobre esses LLMS, mas para tradução eles funcionam bem. Na hora que o serviço de tradução da Google chegar no nível de algo com o Kagi eu acho que vamos furar várias barreiras globais. I.e., Nostr "Japonês" continua sendo uma das minhas distrações favoritas.
Eu não gosto de tradução automática, mas o @npub1gcx…nj5z acha que é o futuro.
Except that I managed to lock myself out of the group already hehehe. I made fiatjaf an admin before pressing the wrong button lol, hopefully he'll accept the invitation and let me join again 😅
Hmmm you're right. I have a port collision on my machine =\ Should be fixed now
https://lnd.sebastix.com/.well-known/lnurlp/sebastian
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 🤣🤣
Ok, so let's keep it up with 0xchat for now. 🫡
I'm using 0xChat (I was tempted to create a MLS group, but since NIP-EE / MLS isn't merged yet I went with NIP-29, but happy to explore other channels as well). chachi.chat is another great client for web / Desktop.
Nice. Which client you use?
@nprofile…wfzm Can explain commukeys better.
If anyone else interested in Khatru wants to join a dedicated NIP-29 group, here you go (works great with 0xChat and Chachi). I made it a closed groups just to avoid spam but everyone's welcome.
#naddr1qp…8v3g
https://haven.accioly.social/f41b0c539a887fecf9c42c4f3daf6c9e57c5daa204fc8e923e08ddfaff7b53f6.png
#khatru #framework #relay #blossom #devstr #nostr #golang #nip29 #community
If anyone else interested in Khatru wants to join a dedicated NIP-29 group, here you go (works great with 0xChat and Chachi). I made it a closed groups just to avoid spam but everyone's welcome.
#naddr1qp…8v3g
https://haven.accioly.social/f41b0c539a887fecf9c42c4f3daf6c9e57c5daa204fc8e923e08ddfaff7b53f6.png
#khatru #framework #relay #blossom #devstr #nostr #golang #nip29 #community
I dont even know what communi-key is. But happy to join if it's everyone's preference. I've created a NIP-29 for no. If a wild @nprofile…xuyp decides to pop-in I'm happy to make you an admin :).
#naddr1qp…8v3g
I don't know such place but it will be great to have one. I prefer communi-key against nip-29 as well.
My Khatru/Rely relays are mostly on DDSRs repo.
Also, fiatjaf is getting unbotherable/botherproof. 🤯😂 (JFF)
Will do, I have been on vacation for sometime but quitely have been working on some things.
More to be published soon.
I'm an eternal newbie at everything Nostr 😅. It would be awesome to have a group where we can collaborate outside our usual circles. I'm getting a bit jealous of the Relay-based group folks who, you know, actually get to chat with each other! 😊 I think there are likely at least a couple dozen people building Relays with Go who could help each other out.
I'm happy to create a group if anyone else is interested.
I'm not aware of one. But I'm a bit of a khatru newbee.
Similar story here. Nostr’s early-days-Internet, "best effort", extremely flexible and hackable architecture certainly attracts some great people—even if their voices are a bit lost on Nostr. I really want to see it take flight anyway.
Well, despite all of my geeky bitterness above, as long as doers and builders from different backgrounds keep hanging around here, building cool stuff in their respective areas of interest, we're definitely heading in the right direction.
The last time I heard the name Henry Story he was still at Su. I'm glad his interests outlasted the company. I need to catch up with what he's up to nowadays. Nostr is full of people like this. Unfortunately, not a lot of academic researchers (yet), but we do have some very smart folks from the torrent/DHT side of things; some folks working on building an Internet Archive over Nostr; others trying to create communication infrastructure for vulnerable people; some aiming to put the “D” back in DVCS; lots of security folks (and I don't even need to mention the crypto crowd again), etc.
Hopefully good things will come if we keep stirring the pot.
Thanks again Dan. You are building some impressive foundations here. Looking forward to see folks adopting more NIP-34 stuff on Nostr!
Hey, you're commenting in the right post if you're looking for human interaction. Unfortunately, the whole "my replies rarely get seen" (or at least acknowledged) is pretty much the standard Nostr experience... at least for now.
When it comes to kind 1 notes, there are basically two ways to get noticed on Nostr.
**First option:** A "Nostr Influencer" acknowledges your note, making it safe for all the "libertarian free thinkers" around here to interact with you. The options here are pretty limited... You basically have to write about Bitcoin, eating meat, or "owning the libs" (and yes, you have to pretend you're American). Ideally, you post a photo of yourself with laser eyes, paying for a burger (no salad, and the buns are also made of meat) while wearing boots on your head and high-fiving Donald Trump. Then zap yourself 10k sats from an alt account and pray Jack boosts and comments on your note. That'll do it for sure. All twenty or so active npubs that aren't bots will notice your post 🤣.
**Second option:** You bring your own wacky, supportive friends to Nostr to interact with your stuff. Other talkative folks join your cohort, and soon you'll be starting hell threads unintentionally. The prerequisite here is actually having friends willing to put up with Nostr's current content. Unfortunately, I don't have many.
I really hope we move more towards the second outcome, as the content on Nostr is beyond boring at the moment. And the algos unfortunately seem to make it even worse. The more people doing their own thing *and* absolutely flooding Nostr with content to the point that current Nostr celebrities can barely get any traction, the faster Nostr's network value will reach its true potential. Or at least, I hope we get some sort of return to the early days of social media, when people acted more naturally, instead of what we have now, with all the "Mastodon-approved content" vs "Nostr-approved content", etc. It's wild to have so many decentralised social media options just for humans to default to standardised behaviour anyway.
David Bowie rocks by the way!
Ngit-relay has an optional 'proactive sync' that checks every 45m whether the git repo matches the state event and if not, tries to catch up by syncing with the other git servers.
The intention is that it would also sync nostr events from other listed relays too but that isn't built yet.
So if you always pushed to the nostr remote, which creates and sends the nostr state event first, and so long as at least 1 git server got your update, the others should catch up.
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?
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what hopefully no longer breaks eventstore filters \n\n#nevent1q…02ly
Amethyst style comment with nak
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what breaks eventstore filters \n\n#nevent1q…zcc9
Amethyst style comment with nak
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what breaks eventstore filters \n\n#nevent1q…k4pz
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what breaks eventstore \n\n#nevent1q…4ulr
Amethyst style Kind 1 comment with nak
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what breaks eventstore \n\n#nevent1q…4ulr
Amethyst style Kind 1 comment with nak
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what breaks eventstore \n\n#nevent1q…4ulr
And this is the Amethyst style quote using both e,"event_id,"","mention" + a regular q tag. This is what breaks eventstore \n\n#nevent1q…4ulr
And this is a dumb quote from nak \n\n#nevent1q…y7yf
And this is a dumb quote from nak \n\n#nevent1q…y7yf
And this is a dumb quote
#nevent1q…6633
If you set up your repo on nostr with `ngit init` and selected 'relay.ngit.dev' then the repo would get pushed there. I'd expect people to clone using the nostr url and they could still clone and raise a PR after you deleted on github.
Thank you 🥳 ,Gm
And Gn for me 💤
Also, I'll definitively try to run the soon to be called grasp relay. I generally have a gazillion small repos with my own dirty hacks around. I don't want to burden public relays but would like to expose some of these stuff to other nostriches. Since Haven is Khatru based maybe in the future I can even hack it for my personal repos as well :). Thanks again for all of your work here!
Also, I'll definitively try to run the soon to be grasp. I generally have a gazillion small repos with hacks around and don't want to burden public relays. Since Haven is Khatru based maybe in the future I can even hack it for my personal repos as well :). Thanks again for all of your work here!
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.
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 from relay.ngit.dev then they would be able to open a PR as per your post above correct? But will they be able to clone the original contents from nostr 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 until be that big of a deal.
If you push using the nostr remote, it will publish your state to nostr. In the future there might be git nostr tools that find the data related to that state from other sources when the git server link(s) listed in the announcement go down or are deleted. On a relate front, check out https://ngit.dev/relay soon to be renamed 'grasp'. Think blossom but for git. The same 'finding lost assets when the link breaks' ideas apply.
And this is a quote and should also be tagging the note bellow.
#nevent1q…2vlk
This is a comment and should have an e tag to the test note above.
Thanks. What gave you the 'works on my machine' vibes or do you mean specifically getting it to work with jj?
You view and restore old versions at https://nostr.land/restore. Check that it works by unfollowing and following someone
Follow sets are TBA
@nprofile…4yzk you wanna take the wheel on this one?
Nah.
Family is over screens this way. Sorry.
🤷
Teaching or taking my kids to a new park, trail, etc brings me more joy than learning to code social media.
Shit ruined humans... look at us now...
Summer of 2008 was peak humanity.
It’s a good point though. Thanks mate
We probably won’t be recording but I’ll do my best to summarize after the fact and post a note.
If it can’t be found on local cache, use the current user’s read relays and author’s write relays.
I made this work by editing my hosted domain’s .htaccess file.
*Economic zone 826
I understand if English isn't your native language.
Foto is by @npub1r6a…utq5
Does haven support BUD-05 /media?
With publications that are targeted at #Communikeys, the first thing we look at (as an App) is the communities server(s).
Nowadays you can use Nostr too for social bookmarking, so self hosted (relay) is optional. All open source. @nprofile…rt7r , @nprofile…utw0 pinja, @nprofile…tgct CCNS
Omg thanks for going on all of these quests 😅
I like giving zaps more friction because I dislike accidental zaps.
https://catallax.network
exactly what we're doing with #catallax . 100% nostr and decentralized
On it.
The Job board is done, now building out the opportunity for Freelancers to post their Services so both directions will be available (Jobs and Bids on them, Services and Orders on them).
I would say we're 90% done with the MVP but I've already used it for multiple Jobs (and a handful of others).
I think linked in is cringe because it's full of corporate boot lickers virtue signalling to their overlords. I think that's the last community to get onboard with nostr. However, that kind of social control lends itself to being disrupted. A network of professionals building on sovereign information and money could catch on and create a renaissance.
Need to add the Access-Control-Allow-Origin header to allow requests from other origins, otherwise web clients won’t be able to retrieve the wallet information.
Error: 'https://accioly.social/.well-known/lnurlp/anthony' from origin 'https://jumble.social' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Issue with Haven
I might be the only person doing this, running a Haven docker image in Portainer on Umbrel OS connecting via Tailscale.
Haven is running, I can connect remotely from devices with a web browser, Nostr client shows relay connected, but…
notes are not sent to it.
I created a GitHub issue (hopefully the right thing to do), more details there.
#asknostr
ask @npub1utx…50e8 @npub1a6w…0tyc
https://image.nostr.build/c7179f753fe7b5be499a5005601bbe986e7746977f2130bc38396157d7ae3dc6.jpg
#haven
The sdk supports it, and its pretty easy to make a http request but I don't know of any client that supports it yet
You are absolutely correct in the facts you provide and the assessment you make.
But I come from a world in which if companies or industries fail then you allow them to fail.
No one needs street lamp lighters or fax machines anymore.
I have also never seen any government effectively run a company.
Don't waste time on a dying industry, pursue thriving ones.
We still need steel, but clearly the market doesn't make it efficient for the UK to produce it.
Also, try not confuse different arguments, saving jobs for individuals is at the expense of the nation.
40 years on, there are no unemployed fleet street hot metal operators, they moved on.
Just a bot reposting what Trump specifically has posted to Truth Social, not a bridge.
there waz 2 notifictionz on last 24hr- to & back- on friendz fruitphone 1-flashflooding 2-tornado warning}10 to 20 min. b4 entering th@ area fFs/lolz*****p'O;.;O'r kid waz freaking o_0'
When I first started with Nostr back in 2023, IPFS sounded like a perfect match. But the more I played with it, the more convinced I became that IPFS is a broken and failed project. Nostr needs something simpler and more straightforward—and then @nprofile…wj75's Blossom came.
Ever since then, I've been dreaming about redundant decentralized storage with file fragmentation—something like what StorJ describes in their white paper:
"All data is encrypted and sharded using Reed Solomon erasure coding. The resulting pieces are distributed around the world. A typical large file is divided into 64 MB encrypted segments, and each encrypted segment is divided into 80 erasure-coded pieces—any 29 of these are sufficient to reconstruct the original file. Each of these 80 pieces is stored on a different drive globally, spread across diverse geographies, operators, power supplies, and networks."
In Blossom, this would be a killer feature. You would offer space on your server to others, and in exchange, get redundancy for your own files, or you would simply pay for it. File metadata could be published as a specific kind hosted by relays.
Torrent was designed over fixed large data. I'm not sure what would happen if the dataset you are syncing is constantly changing.
I think using mainline DHT to bootstrap a pubkey's relay list is a cool idea. But we instead just spread these relay lists out on the current popular relays, which works well once you've been using nostr for a while and your client can easily figure out which relays are popular. DHT would be better for people starting cold though.
Yeah right now I just have a user agent list and that does most of the work, the bots that are hitting me mostly have "~bot" in the user agent field so it's been working to stave them off for now. I have to hop in and update the list every few days it helps.
I was interested in rDNS lookups for blocking since most of the IPs i've dealt with come from rDNS bot sources like bytedance, openai and so on.
Just tested and responded, working perfectly! Thank you my fren 🫂
> there is no point in doing sliding window spidering on events once you have the history, from then on just open a subscriptiion
I am not following sorry. My crawler does this:
- Firehose: subscribes for new kind3s and kind0s
When a pubkey that is in the database is "promoted" (has acquired enough reputation)
- Query: query directly for its own kind3s and kind0s.
The query starts when one of these two conditions is met:
- One minute has passed since the last (with at least one pubkey)
- There are 100 pubkeys that have been promoted
Normally the crawler in production promoted ~100 pubkeys/day.
However, when I do tests locally I re-do the entire crawl which obviously is much more intensive, but I'll make sure I'm not using your relay for that sir.
this stuff annoys the hell out of me too, i run my test #realy fairly infrequently but within minutes some bot is trying to scrape it for WoT relevant events, and i wish there was an effective thing to slow that down
i tried adding one kind of rate limiter but that didn't really work out so well, in the past what i've seen work best tends to be where the relay just stops aswering and dropping everything that comes in... probably if that included pings the other side would automatically drop
i've now added plain HTML and i think that requires something also but maybe more simple, like, if it gets a query more than once every 5 seconds for 5 such periods it steadily adds more and more delay in processing, the difference to sockets is to do it on http it has to associate with an IP address
FHC teve seus excessos também: usar emendas para "comprar" o congresso em troca da aprovação da reeleição, por exemplo.
Não acho que salva nenhum.
Ironically, I asked Venice AI to write me an Android app in Kotlin that displays "Hello World!" after the user presses a button. The amount of errors the code had was staggering. I think all LLM's have code to identify me, and return trash 100% of the time.
@npub1qdj…fqm7 @npub1wqf…qsyn
Everyone on nostr likes these feeds, that's why we're here (survivorship bias). The issue is all the people who try it and leave, which according so some stats is 90%+ of people
Clojure mentioned @npub1jlr…ynqn hodlbod hodlbod
H/t to all the great folks for code and inspiration @nprofile…l3vp @nprofile…6u4e @nprofile…dlnm @nprofile…0p5w @nprofile…pyug
Yeah, Amethyst bumps boosted posts. My ideal Frankenstein Nostr client for short notes would basically be Amethyst with Listr/Nostur list curation capabilities + Nostur’s "Remember position in timelines" functionality + Gossip’s proper NIP-65 support so I can actually find content from the folks I follow (and vice versa) + Jumble/Nosotros like relay feeds. And for good measure, I’d throw in 0xChat’s NIP-17 + E2EE messaging using MLS.
Basically, Nostr clients already have everything I need for an awesome content discovery and curation experience. Just not in a single client... yet. We'll certainly get there!
As for getting folks to understand that sharing/boosting is caring... now that’s a hard, non-technical problem to solve.
PS: Fedilab, despite its quirks, configuration overload, and far-from-award-winning aesthetics, has implemented everything I just mentioned for Mastodon/ActivityPub in a way that really makes chronological feeds work. If any client devs want some inspiration, I’d definitely recommend having a look at it.
Amethyst.. really? I must have missed this, is it a recent change?
I do agree though, sometimes I won't boost only for the reason that I've seen many people in my follows list already boost (silly as that might seem, its true)
Some clients already combine boosts, bumping the note higher in the feed. Amethyst & Damus I know of.
I have no idea how to hardly use GitHub or obtanium to download stuff much less code anything lol. I will contribute to it though because I can see the worth of it
Add @npub14ag…dadk and @npub1a6w…0tyc
TLDR: Foreign lady learns that there are laws and that jail is designed to make you never want to break the laws of a country you aren't a citizen of despite thinking she is special and that laws shouldn't apply and that jail should be cozy.
for scheduled notes there's https://shipyard.pub/
but cross posting, idk...
Already tried it with Coracle, but no luck due JS errors... /cc @npub1jlr…ynqn
Yes, of course. You can send PRs here: https://github.com/HolgerHatGarKeineNode/haven-docker
I always use my own Nginx server as a proxy in my infrastructures, so I haven't had any need for this so far. If someone wants to start an Nginx proxy with Docker, they will be happy to have an opportunity to see how something like this works.
I am also a fan of traefik.
Ok so I should have explained the rep system a bit more. So far there are 4 trust levels untrusted, neutral, positive and trusted. Each level has different limits. If you maintain untrusted status for a set amount of time (default is a week but its configurable) you get dropped. So you don't get kicked off the relay right away. There is time to recover.
On your first example my only pushback is I don't like logging IP addresses for user privacy reasons and try to avoid it when I can, but IPs are also public so /shrug I might do this but right now I'm not. I kinda like the idea of lowering rep for repeated rate limit failures. This could help with bots that are not necessarily bad but post a lot if random stuff IE I've seen some bots that repost MSM news every minute or so, if no one was interacting they would be dropped eventually.
The community mod thing kinda sounds like what ditto does, but it's all on the relay admins to make the final decision on if they get kicked or not, but it's all based on user reports. (it's not a voting system like the one you describe, though) and that was kind of my attempt with the 1984 reports. They are weighted a bit stronger that normal things like spam check failure, and invalid Nip-05's
I'm debating making an admin interface that has things like banned Npubs or something so it's easy for admins to unblock people if they want. But right now it's not something I'm super worried about.
I see both notes and there are replies there. https://image.nostr.build/e72642584fd3d0afe7a4d2f4ebb6b9374822d4584c09bd3837bd94840ad892de.jpg
Nostr has been pretty quiet the past two weeks and it's still hard for new npubs to gain reach.
I still connect public relays and just do client-side friend filtering. Wot relays aren’t the way.
