My point was more about training than going to an actual gym..

but also this:

note12mdhhuukh55pmyf0gx0y60qd3zgtzyxu4edgcx3wnuprp7p5g7kqe7t6tf

I might be projecting but that stance feels like a cope.

worst case scenario there is as much risk in developing on nostr as there is on going to the gym.

rewards depend on your goals and whether or not you are doing the work

what if I am a dev?

Do we have a nostr native one yet?

#tunestr #zap.stream #spotify #asknostr

the problem I see in this reasoning then is how many generations? and how high a fee? with centralized mining, this is definitely a threat.

I don't think we're in doomsday scenario yet. and my guess is we'll see more mining pools rising to the occasion in the coming years, with governments and corps taking more of an interest. we'll have to see.

então sua ideia é a plataforma, sem consentimento do usuário, coletar informações sobre o usuário e alterar o conteúdo do evento que ele vai assinar para refletir de onde ele vem?

aí você recriou o problema que nostr resolve

você acabou de descrever o caso de uso de hashtags. #nosbr

é importante considerar que:

1) existe usuários brasileiros

2) existe usuários que querem encontrar outros usuários brasileiros

3) existe usuários que querem ser encontrados por usuários buscando brasileiros

para garantir a intercessão entre esses 3 conjuntos, é necessário que exista alguna forma comum a todos de identificar esses usuários numa multidão.

daí #nosbr #nostr-br #brasil #portugues #portugues-br #pt-br #pt_br e por aí vai

numa rede descentralizada onde a responsabilidade por divulgar e encontrar conteúdo recai no usuário, depende dos usuários utilizarem a ferramenta a disposição para isso.

please read the whole conversation he has with nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp

it's more relevant than the clout generated by this screenshot.

more conversation, less friction. let's not create unnecessary conflicts.

I don't think that is universally true, unfortunately.

I am under the impression that representative democracy as we know has slowly shifted from promoting and defending ideas, to promoting and defending a representative. and a consequence of that is that it creates a false dichotomy, because people will be in favor of/against a representative. while ideas provide a more granular basis of consensus.

I actually think people agree far more onany issues. and they are being distracted by a popularity contest

torrent is not used by a broader audience or in any similar way to how social apps work.

there might be some use cases for p2p client/relay architecture, but it won't cover all that #nostr can be used for.

Not every user will be equipped to build, maintain or even run their own client/relay safely. These users will require either third party clients/relays as a service, or third party software they are not equipped to manage on their own.

That does not translate in a true p2p network. there is still a chance fewer such trustworthy projects will support most users. Where are they hosted? who maintains them?

true p2p is not feasible. there must be something in between.

on the other hand #nostr already allows for p2p networking when honest alternatives aren't available. p2p alone cannot scale.

so this would be a way for me to validate that whatever the host server is sending me is signed states only, but requires that whoever is pushing signs an event. I think I get it now. thank you for the explanation.

my instinctive thinking is that git trees are very sensitive to unexpected changes and often plagued by conflicts over inconsistencies in the source code between remote and local copies. I am also assuming that maintainers hold the source code in a local copy. so in my mind, it is hard to force push changes that wouldn't be caught by git. then, the fact that you can just migrate your work over to a different server in a frictionless manner be enough to address the issue from the maintainers perspective, detect malicious intervention in codebase, update the repo announcement with a new remote url and it's done.

but I can understand that if we can actually prevent that from happening, by rejecting a push/fetch altogether based on a distributed state it does provide a better experience. thank you again for the explanation. I'll have to make adjustments on my side.

I am out of my depth here in regards to maintaining open source repos. I need to read more about the threats that this solves. mind sharing some references?

oh.. I was purposefully ignoring that. since I am allowing git to get all the references from the repo itself.

what is the perceived benefit of having state outside of the repo itself? git already does a good job figuring out states for itself. doesn't that open up the possibility of eventually consistent states when fetching?

right, I skipped the nip-34 because I always need to fetch it. I was only focusing on the identity part because it is only required for uploading.

full flow starts with fetching the nip-34 announcement to get the actual remote url, because it can be a GitHub url, so before considering auth I need to check that. that's done for all commands.

for upload specifically, if the remote url is pointing to a relay that supports nip34, then I try to auth. and only then allow ssh to attempt to connect.

if connection is successfully, git and ssh will do the rest.

are economic incentives the only ones we care about?

I kind of like the idea of conceptually distinguishing between clients and relays.

a client is an application that connects to relays to pull/push notes

a relay is a server that accepts connections and processes notes in the specified schema

those are abstract concepts. if an application implements both interfaces it's capable of P2P.

if you want to own your data, you need ro run a relay. isn't that where the incentives lie? the economic incentives are created by people who don't want to run their own relays.

I think the question then is: can only P2P exist? is there no room for something in between centralized platforms and P2P only?

if all the network were to reject you, no.. but that is on you... rejection and censorship are different

I'll give it a read asaic. interested in learning what you guys are doing.

found it

where can I find the code for git-remote-nostr?