Guga Figueiredo

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.

2024-09-05 05:56:55

https://youtu.be/Fstac3_ZVeY?si=U0C1hF0IQEqz3gsl
Metal, voice and research
#metal #nostr #research #voice #music

2024-08-26 19:34:13

- reply

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.

2024-08-26 16:55:43

- reply

to allow identity validation before ssh connection and push execution
then how that auth happens would depend on the relay. it can use a bunker, ssh ca, rolling keys, these are some of the ideas I had. I am trying to create a poc with rolling keys.
git push triggers AUTH flow,
helper sends an ssh pubkey with the auth event
relay validates identity of sender, registers key with local ssh server
on OK helper attempts ssh connection
everything else is git doing its own thing

2024-08-26 10:27:12

- reply

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?

2024-08-21 18:05:18

- reply

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

2024-08-21 17:53:30

- reply

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

2024-08-21 17:48:02

- reply

found it

2024-08-21 17:38:37

- reply

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

2024-08-19 14:43:43

- reply

I don't think there is a single way to do stuff right, so I don't believe there should be a single unified way
I'm my mind, the expectation is that nostr provide a common way.
that way we can have IGstr, Twistr, FBstr,
but also UTubstr, Rumblstr, etc..
each one will.do things a different way. some will grow to do more than one thing and they will be good. but he expectation is that migrating between solutions should be painless for the user

2024-08-18 07:01:25

- reply

my point here is more that not everyone is going to be turned by the same use case at the same time. so, on top of what you said, we should adjust our expectations accordingly

2024-08-17 22:11:04

- reply

I'd argue that it stems from the mind viruses we got from fiat thinking, that creates this expectation that something needs to be adopted by critical mass user base in a very short timeframe.
nostr grows with builders, building their idea. we don't know which use case is going to turn everyone. it might be cat memes, it might be freedom money. time will tell

2024-08-17 20:25:37

- reply

we need other stuff, just notes won't cut it

2024-07-29 19:12:14

- reply

Unfortunately the democratic system as we know it does not reward that strategy

2024-07-27 09:24:17

- reply

3 actually.
https://gitworkshop.dev/ by @npub15qy…yejr
mine is way less ambitious, but check it out:
https://github.com/gugabfigueiredo/git-remote-nostr

2024-07-24 22:58:56

- reply

well put.
people are playing debates rather than having conversations and exchanging information.

2024-07-23 17:28:21

- reply

I actually think there is a point to arguing. information exchange is invaluable, even if people don't ever come to admit it.
What I think is a problem is sometimes is that people assume that because they think they are right that others will change their minds if they articulate and assert it well enough, and then get mad because others seem unconvinced
In that case, as you said, might be better to just move on...

2024-07-21 07:12:49

- reply

I consider myself anti-gun in the sense that I don't think having guns actually protects you from states, because the damage caused by states to its people is no longer correlated to their ability to bear arms against them.
the argument of the US 2nd amendment, however valid at some point in time, seems to me to have been completely nulled at this point.
IMHO, violence and armed conflicts are more a symptom of a failing system than a strategy through which to defend or advance any idea.

2024-07-20 09:35:58

stop asking for permission or approval, just create the damn thing!!
THEN you present it and argue in favor of it.
I see this pattern emerging with people asking if their idea should not be integrated into #nostr.
if you don't think it is worthy building it without community consent, there is your answer!!
#grownostr #buildstr

2024-07-19 08:24:36

- reply

I distrust government, but to see the discourse change is exciting.
I'm sure they are going to fuck it up though

2024-07-17 20:31:47

- reply

same argument applies for those techs, most people don't understand the layers of technology behind the screen of their phones, and the protocols they are built on top of. just that functionalities work. and that is what most people care for.
we must remind ourselves that not everybody is interested in Nostr the protocol.. just in the network effect. if Nostr is in fact the better technology it will attract builders who will use it to build the future of social networking.

2024-07-17 10:10:01

- reply

we are so early.
as we spend time with these new technologies, we forget that not everybody is actively seeking information about it.
most people don't really understand how email works, just that it does. and his will be true for while still with Bitcoin and it's technologies.
that said, it is important to always explain patiently to people and encourage them to learn more.
things will get better

2024-07-16 19:40:55

- reply

No mundo fiat tem mais coach quantico querendo vender dicas de sucesso do que empreendimentos honestos que atendem a demandas reais de usuários
Desfazer a centralização de capitalização de tráfego de midia digital e redes sociais significa que esses mecanismos nao podem mais ser explorados para fomentar tráfego para um negócio e inflar o lançamento de um empreendimento.
Nós estamos observando diversos novos negócios e empreendimentos, orientatos a lucro ou nao, surgindo no ecossistema nostr, mas o próprio protocolo ainda está num período de maturação, comentei isso recentemente num outro post: https://primal.net/e/note10edcl5wk2ax0h07zzjlvuxrjz2cs9mazdwvsjcq5yvqcxqea5z2qww22wa
Acho que é útil pensar em como funcionam os ciclos de vida dos processos centralizados e descentralizados.
Um processo centralizado tem uma meta/demanda definida por um planejador centralizado (stakeholders). Esse objetivo ajuda os desenvolvedores a coordenar esforços para uma gama limitada de casos de uso. Então, soluções para esses casos de uso são criadas. E repita. é muito direto e ágil (haha), mas essa demanda pode estar superestimada, pois o planejador central pode estar errado, ser incompetente ou desonesto.
Os processos descentralizados têm um ciclo de vida de desenvolvimento mais “orgânico”. Os desenvolvedores criam com seu próprio caso de uso em mente. Quando um caso de uso se tornar popular (ou seja, quando há demanda), a adoção pela comunidade ajudará a orientar o desenvolvimento dessas soluções. Isto é mais lento e não existe uma linha de chegada clara, uma vez que a procura evolui com o tempo. Algumas soluções podem ser abandonadas ao longo do caminho. As soluções sobreviventes serão as que realmente agregarem mais valor, pois há uma demanda contínua.
há um caos natural na forma como os processos descentralizados funcionam e os prazos diferem dos centralizados.
As pessoas só podem desenvolver as ideias nas quais veem valor. Só o tempo dirá quem está certo ou errado.

2024-07-16 08:42:44

- reply

Not sure these count as non-social
GitHubstr
StackOverflowstr
Kickstartstr
I'm working on bridging git with nostr
https://swarmstr.com/ has the stackoverflow look and feel on the way, kinda
https://geyser.fund/ has the Kickstarter thing working
https://gitworkshop.dev/ and some other projects are trying to create a GitHub like experience
So I'm super pumped to see what will be available in the next years

2024-07-14 16:04:12

- reply

"don't trust, verify" exists for that reason.
there will be honest actors creating amazing utilities that will make life easier and all together better.
there will also be scammers and incompetent actors with empty promises.
we must differentiate ourselves from fiat grifters by clearly stating what might be obvious to some of us.

2024-07-13 20:17:19

- reply

please expand

2024-07-13 15:17:10

note1fysth6ludaunzpnqxe6ndm6xqvv72w6wh2n6m2z657tul4hzeyws26w8e4
#asknostr #grownostr #pollstr

2024-07-12 23:39:31

- reply

it's a process people.
we are building foundations, not just services
keep building

2024-07-11 19:35:42

- reply

By all means, give it a try. Just adjust your expectations as you progress. It might be that it takes longer that you might have imagined or predicted. It might be that the solution you are interested in is not in high demand, and that people will flock behind a different idea.. even if that idea comes to fail at some point in the future.
and on that note: https://x.com/geyserfund/status/1811434402041282680

2024-07-11 17:10:43

- reply

what a perfect demonstration of decentralized development process. beautiful to see in the wild. people need to understand this is the process. smart minds trying to do their best. time will tell what there is actual demand for

2024-07-11 14:43:06

- reply

I think it is helpful to think of how centralized and decentralized processes life-cycles work.
A centralized process has a goal/demand defined by centralized planning (stakeholders). This goal helps the builders coordinate effort towards a limited array of use cases. Then, solutions for those use cases are engineered into existence. And repeat. It is very straight forward, and agile (haha), but that demand might be overestimated, as central planner might be wrong, incompetent or dishonest.
Decentralized processes have a more "organic" development life-cycle. Builders build with their own use case in mind. Once a use case becomes popular (ie., there is demand), community adoption will help steer development of these solutions. This is slower, and there is no clear finish line, as demand evolves with time. Some solutions might be abandoned along the way. Surviving solutions will be the ones that actually provide the most value, as there is continuous demand.
there is a natural chaos in the way decentralized processes work, and time frames differ from centralized ones.
The fact that this https://github.com/nostr-protocol/nips is the current reference for how nostr is supposed to work is a coincidence. There is no guarantee that this will still be true in 5 years.
People can only build ideas they see value in. Only time will tell who is right or wrong what works and what doesn't.
I would advise people to be wary of making or blieveling in "this is how things should be" arguments when it comes to the development of decentralized projects, as such arguments are filled with bias and projection. in an organic decentralized process, you can only look back and say what has worked best so far. there is no telling how things should be. any predictions are only that, and have no bearing on reality.

2024-07-04 07:34:35

- reply

I agree with the statement.. but coming from Udi this sounds like a troll statement for some reason

2024-07-03 20:35:14

Hey @npub15xd…t3l3 @npub1w5e…4084 @npub1dtg…up6m
Are you guys aware of https://wanderlog.com/
A friend showed me this today. It looks pretty impressive, more utility than display. Something to consider for the roadmap?

2024-07-03 05:12:41

and here we go, what do we do with shitcoiners and scammers on this platform? you picked the wrong place to come do this bullshit man.
@npub1lk2…8cku
https://m.primal.net/JGOK.png

2024-07-02 17:03:29

- reply

YES!!! This is awesome! My dream stack is almost a reality!! Lets go Nostr!!!
Thanks for bringing this to my attention!
I'm adding @npub1swr…73v6 to my watchlist!!

2024-07-02 13:29:01

- reply

I say let them die in peace.. #proofofwork . the apps/devs that are doing the work will create a beautiful nostrverse, on top of a lot of failed projects. not all clients/apps will survive

2024-07-02 12:17:42

- reply

I'm thinking I'm terms of nostr native apps, that provide functionalities and services. like @npub1kmw…xqk9 , @npub15xd…t3l3 and so on.
what is something that could make nostr events more meaningful to you, beyond the purely social aspect?

2024-07-02 11:33:18

- reply

I do think the zap culture is a positive thing though. it shifts the incentive forces from ad-revenue and private funding to consumer centric incentives. I feel like that's why it's so talked about and why people get excited about it.

2024-07-02 11:25:52

- reply

also, are you sure you are following the right crowd? I was pleasantly surprised by how much people are working on similar concepts to me. projects I was completely unaware. it might just be the case that you haven't seen everything that people are building

2024-07-02 11:23:52

- reply

any specific applications you think would be a good addition to the nostr universe that might appeal to a larger audience?
I'm very interested in FOSS alternatives for popular platforms, for example the ones I commented on the quoted note.

2024-07-02 11:13:10

Let me hear from you guys. What are the most exciting things happening in nostr for you? Whos is building the future you want to see on nostr?
#asknostr #pollstr
#note1fys…w8e4

2024-07-02 11:10:38

- reply

I might be on the conservative side regarding this. PRs are not first class citizens in git. so an integration of nostr+git doesn't need to have PRs.
I want to be able to work with git and nostr side by side. I see clear benefits in decentralization just by reducing friction for handling git server/service migration. And don't want to see nostr native repos become incompatible with regular git ones.
most of all, I like the idea that there are layers in the solutions we are exploring, and I'm hesitant to have protocol definitions across many layers. I don't think every good idea about how to do things in nostr need to be a protocol spec. it incentivizes gatekeeping and hinders flexibility. taking us closer to how centralized solutions work.
I am working on some ideas to improve the remote-helper I've made. Should have an update soon.

2024-07-01 21:47:46

- reply

That is mixing git workflows and git service functionalities with core git commands, is that right? if I understand correctly, I don't know how I feel about that. my instinctive response is that pulling/pushing code should be all that the transport protocol should care about.
And I think there are more things we can do with nostr to improve UX working with git remotes hosted over nostr on that front, before thinking about adding overhead with what I consider is more a UI concern.

2024-07-01 21:26:11

- reply

So what are we gaining by adding nostr to that flow beyond the ability to find the server?
My thinking has been going towards doing that server side, for the purpose of providing frontend functionalities, notifications, but that would have no bearing on the remote-helper transport for pushing/fetching.

2024-07-01 20:53:23

- reply

Doesn't that just makes any maintainer a single point of failure? A malicious or careless actor can still cause damage, much like with regular centralized git servers. we just added more steps to verify that. isn't it?

2024-07-01 20:33:32

- reply

I understand the concern over centralized servers, but all these refs flying around notes make me concerned about eventual consistency. isn't it enough to setup mirrored servers, that can be tapped into if one of them is compromised? Shouldn't the code owner be the one responsible for that?
if we are going to duplicate refs on nostr events, we are bringing git concerns to nostr events.. once a connection is established with a git remote-helper, git is the one listing refs in the server, and we are going to have to keep the server we are connecting to consistent with the notes we are serving on nostr
what prevents malicious notes from creating false refs, in that communication?

2024-07-01 12:01:56

- reply

how to be sure you're fetching from the latest, most recent updated source?
my assumption is that it is something that the code owner is the one ultimately responsible for providing, and he would put that into the repo announcement on nostr. then, you only need to use that noatr remote url to patch through to git

2024-07-01 11:58:34

- reply

I see your point.
for the friction part, that is precisely what I aimed to treat with my project. a simple update to the repo announcement on nostr and everyone cloning from your nostr remote will still reach your git remote

2024-07-01 10:32:52

- reply

what is the argument to reduce git servers role? I am being conservative about replacing things that work natively with git to reduce friction when migrating between solutions

2024-07-01 08:51:08

- reply

oh, hi! yes. that would be awesome!
I had already started working on this when I first became aware of git workshop.dev and your other projects a little while ago.
I would really appreciate the opportunity. I mostly want people to try it out, see what it feels like and what is missing/desired from such a tool, if at all.

2024-06-30 19:03:35

- reply

while the effort is appreciated, I find hard to believe a single app can adapt to everyone's needs and display all kinds of content in their optimal format.
the reason we use multiple platforms is because they are hard to build even when specialized. information wise, I'm with you. but there are functionalities and use cases that are just impossible to get all in the same place.
that is the greatest thing about open distributed networks and development. many solutions and apps are going to be created to try and map some use cases. nostr allows us to use them in tandem with each other in a frictionless manner.

2024-06-30 18:34:26

- reply

Powerfull speech. But I trully believe the days of central government and elected representatives as we know it are numbered. Even if I believed @npub1sg6…f63m or even yourself would push all the right ideas into that system, I don't think that is the future we are moving towards.

2024-06-30 18:26:06

Anybody else got a dream nostr stack on their mind? Which nostr native apps are you guys most excited about?
my dream stack is GitHubstr, KickStartstr, and StackOverflowstr.
@npub1s3h…75wz is working towards git, and so am I.
@npub1kmw…xqk9 has the lead in making that a reality with crowdfunding.
are there any contenders for StackOverflowstr?
#asknostr #grownostr #buildnostr

2024-06-30 18:14:32

- reply

Our thinking is in sync! Awesome! That is either great feedback or we are all very mistaken hahaha. I will carry on as if it's the former.
And it's super exciting to find other people working on this!! I'm pumped to see what will be born out of nostr dev community yet.

2024-06-30 13:13:25

- reply

yes.. and we can have that with nostr. I aim to make that possible. this is my first step: https://github.com/gugabfigueiredo/git-remote-nostr

2024-06-30 13:12:10

- reply

checkout my project: https://github.com/gugabfigueiredo/git-remote-nostr
host your code anywhere, publish the repo in nostr. I aim to allow the creation of nostr native git hosting services

2024-06-30 13:04:38

- reply

checkout my ongoing project: https://github.com/gugabfigueiredo/git-remote-nostr
aimed at allowing the creation of nostr native git host services. more to come soon

2024-06-30 13:01:40

- reply

I'm of the mind that nostr and git can complement each other. GitHub is not git. we can build multiple git host services that have a variety of functionalities and focused on different use cases and user profiles.
that way, parity is not even a desirable outcome. I'd argue for superiority.

2024-06-30 08:48:20

- reply

I have been wondering about some of these things. How much git activity you guys think nostr can/should take? What are you guys considering as git activities? My first instinct thinking of the ability to use git over nostr was to patch all git commands through, while researching, ultimately, I got the impression that it would be a lot of re-work, pretty much implementing all the git stuff. but git is a pretty stable decentralized solution already. Thats how I ended up going for the remote-helper, using git transparently and tap into nostr for discovery and identity validation then felt like a worthy pursuit.
How specialized an IDE one would need to work with nostr? How popular is GithubDesktop actually? I mostly use git straight in the terminal, github is more of a side thought for me, I had already been looking at gitea and self hosted solutions before nostr was even a thing, that was another reason why I wanted a transparent interaction.

2024-06-30 06:58:17

- reply

ambitious! super cool! will be keeping an eye out for what is coming!

2024-06-30 01:06:40

- reply

tell me more! nostr and git integrations specially for documents, is a personal interest. if you guys are working on this I'm interested

2024-06-29 21:56:31

- reply

I am very curious though, what is your project about. I didn't understand it entirely from the wiki

2024-06-29 21:53:28

- reply

So sorry for your country.. I'm hoping Denmark take them out
🇩🇪7x1🇧🇷 never forget

2024-06-29 17:15:14

- reply

While I radically disagree with their point of view, I try to remain sensitive to people's plights.
As someone who once felt misunderstood and cast out because of social quirks and psychological predicaments, I can imagine that people tend to reach for this kind of argument because it speaks to the fact that while merit, excellence and intelligence are, in concept, desirable, the way we have measured that as a society, has been distorted over time.
These unfortunate souls do not realize that while their personal experience might have been negative, the overall result for humanity has been positive, as evidenced by our success at increasing the human population and longevity, in spite of the severe problems that we still do face as a species.
That we fix HOW we measure these 3 attributes to properly assess the value of an individual to our community, and so that the individual might also properly evaluate their contribution to their's, is what we are taught by lowering our time preference. These creatures have such an alarmingly high time preference, that even reaching for such a realization is beyond them.
In due time though.. it will come to them too.
Either that, or oblivion. and so we wait.

2024-06-29 16:38:25

- reply

Git oriented people on Nostr!!!! We need to talk!! I did a thing: https://github.com/gugabfigueiredo/git-remote-nostr

2024-06-28 14:20:25

- reply

how about create repo announcements instead: https://github.com/gugabfigueiredo/git-remote-nostr
my git-remote-nostr helper allows users to announce their repo on nostr regardless of where they are hosting it, transparently integrated with git

2024-06-27 20:25:18

- reply

this is freedom, in all it's glory whatever it is

2024-06-26 08:08:18

Hey #nostr I'd like to introduce git-remote-nostr, a git remote helper to connect with nostr relays for remote urls. Host your code anywhere you want. Share a remote url on nostr.
https://github.com/gugabfigueiredo/git-remote-nostr
I consider this still a work in progress, as some desired features are still being considered, check the readme for more details.
Any feedback is appreciated.
#introductions #grownostr

2024-06-20 01:38:14

centralized platforms have ONE good thing going for them: they force people to use a COMMON protocol.
centralized platforms have one really bad thing going for them: they FORCE people to conform to a SINGLE protocol
forcing us not the way. if you think you can do better, do it, don't waste your time trying to convince people. if your ideia is good enough, people will adopt it.

2024-06-20 01:30:09

- reply

or, we could have a common protocol that everybody adhered to, and that was easily identifiable regardless of the app people are using... can you imagine that

2024-06-19 13:54:20

- reply

I''d argue that there is need for a visual identity for the network, not for the protocol. the #nostr network is the collective of apps, relays, clients and users.
when sharing and identifying things online, it helps to understand that users are sharing from/to "nostr, the network"

2024-06-19 07:08:43

@npub167n…zu3r will recordings of the talks from the conference be available for sharing at some point? I only see Saylor's and Mallers'

2024-06-18 20:05:14

It is a good thing to expose yourself to people who think different from you. It allows you the reflect on your ideas and not get stuck inside your own head. However comforting it is to be surrounded by people who you consider your peers, be careful not to be surrounded only by echoes.

2024-06-18 14:26:58

- reply

such a refreshing and reasonable take
it is crazy that some people somehow think that in order to oppose the violence Israel is perpetrating towards Gaza you need to support Hamas.
be careful of false dichotomies people,
be like Lyn

2024-06-17 21:06:49

- reply

the personal cost associated to moving from Twitter, Facebook and the like into a different network entirely, rebuilding identity and audience, is disproportionately higher than moving between relays/clients/apps. that is one of the major accomplishments of the specs you defined. I mean, says so right in your initial proposal.
what has happened by default with social networks is that users migrate or join the networks with more MVPs. ever since IRC channels, the oldest I can think of.
but moving inside the nostr network should be mostly painless, unless you make yourself a subject to a totalitarian platform, which I expect to exist. and even then, as long as you hold your key, you might only lose data. you can pat yourself on the back for that, sir. this lack of friction is what enbolds me to say that people will abandon bad platforms, as long as they have an alternative. your protocol provides THAT, above all else.

2024-06-17 15:02:13

- reply

maybe I'm not well informed, what is the deal with these other clients? in what way are they not implementing nostr correctly? I feel like an open definition as any means that if these clients fail to provide the decentralization and censorship resistance, they will be abandoned eventually in favor of ones that do
I guess your note landed kinda harsh, making it seem like there is "a correct" implementation. Although I subscribe to decentralization, I have strong reservations regarding dictating how "things are supposed to be".

2024-06-17 08:02:59

this could be interesting
https://x.com/saifedean/status/1802571060379820278?t=W2uqdh5CIfkOaD1CllhVjw&s=19

2024-06-17 07:50:49

- reply

#asknostr: what does a client or relay need to implement to be "nostr-complete"?
I was under the impression that most nips are optional, and it would be a natural selection process that determines what is, and what is not, a nostr-complete application (as in users abandoning one app, client, or relay, because they don't implement the most valued features)
which nips make a client nostr-complete?
and what about clients/relays built for specific functionalities?

2024-06-16 17:47:51

- reply

well.. completely fucked up the order of these notes hahahahaha

2024-06-16 17:47:25

- reply

nostr (the protocol) does not describe a functionality to prevent a user on the network from communicating and sending events to the network. in fact, it doesn't even dictates that can only be a single network. multiple can operate without ever overlapping.
however, clients, relays, and other users can FREELY chose NOT to communicate or propagate content. that is not censorship, that is rejection. being rejected can happen. there is no guarantee that every network will accept every kind of communication

2024-06-16 17:46:03

- reply

built in top of nostr (the protocol) is the nostr network, which is composed of nostr clients, nostr relays and nostr users
users use clients, to open channels with relays, two users connected with the same relay and willing to communicate with one another will be able to do so.
you can pick your clients/apps, you can pick your relays. no one can force you to use one or another. and you can run your own. permission-less.
that means that, as long as you do not give up the rights to your data (lose keys, lose data, host your data on a third party solution with no backup, etc...) if any channel is closed, you should be able to open a new one, permission-less, and re-establish your communication with whoever is willing.

2024-06-16 17:44:45

- reply

2024-06-16 17:36:56

- reply

2024-06-16 17:25:54

there is a lot today about censorship resistance and decentralization.. maybe we need some definitions
I'll start with my own:
given a social communication protocol,
my understanding of censorship resistance is that no user can be prevented from using the protocol to attempt to communicate. and if there is an open channel of communication between any 2 users that want to communicate with each other,
my understanding of decentralization is that a communication channel can be established between any 2 users without the need of third party involvement.
nostr (the protocol) does seem to display both properties.

2024-06-16 13:25:21

- reply

nostr is definitely moving the needle towards the right approach, a public, open, permission less digital identity. which is not profitable or sustainable on the fiat standard.

2024-06-16 13:23:32

- reply

a digital social identity that is recognized and accepted in other platforms is one convenience factor that either attracts or forces people into a network.

2024-06-16 09:32:02

- reply

GM, and safe travels

2024-06-16 02:27:18

- reply

2024-06-16 02:24:48

- reply

I'm almost in agreement on the conclusion. the protocol is designed in an open way. but apps don't need to implement all the openness. and as user needs arise, some walled solutions will be created. it is up to the community to accept or reject them

2024-06-16 02:20:04

- reply

I feel this goes back to a discussion that Zuckerberg had to explain to politicians why the onus of privacy was on the user.
I remember thinking how absurd that question was. and was only a thing because centralized servers of social networks are used as data storage by users, where their designed functionality was to post stuff to public view.
I understand people wanting to prevent unwanted actors and platforms from using and benefiting from their content as if it was consensual. but in a network where the main goal and advantage is the free flow of information, maybe the onus CAN only rely on the user.
the assurance nostr provides is the validation that that content was actually produced by your key. once data leaves your device, it now belongs to the network.

2024-06-15 22:32:13

- reply

that was supposed to say "my first Bitcoin conference"

2024-06-15 22:30:29

#introductions #introduction
hey #nostr let me properly introduce myself. I'm Guga, a dev from Brazil.
@npub167n…zu3r what an amazing experience this has been!!
this was my #Bitcoin conference, and I got to meet and greet @npub15dq…lm5m , however breefly. Got to shake hands and thank @npub1w69…zltw for his role in my orange pilling journey.
got to talk with some of the amazing people behind the rise of #nostr, all the awesome stuff coming up and exchange notes. @npub1w5e…4084 @npub1zga…ppvc @npub19f2…e9da @npub1l2v…ajft @npub18am…p424
my heart is beating orange and purple! 🧡💜
see some of you again tomorrow at the Satlantis meetup!

2024-06-15 19:05:27

- reply

while one can have overlapping knowledge of both, I think those are, at their respective limits, different skill sets, with different tools and purposes.
but I also think it's mostly industry that really sets people in that way. we end up specializing in one over the other to fit a career path, either by design or by circumstance.
I've known some frontend who were mostly designers who knew/learned how to code in one tool or another, but did not have the deeper understanding necessary to do backend. and I would not trust any of the backend people I know to create a good UX/UI, even though they certainly have the knowledge to figure out how to code it.

2024-06-15 17:39:37

- reply

what is the difference?

2024-06-15 17:19:04

- reply

well.. the problem then is that the network is not developed to withstand popular adoption. new users bring demands which creates value which foster development of new ideas.
if nostr as is already good enough for you, awesome, keep at it and have fun. build the best features for your needs. but to provide a platform to face off against centralization of user data for the world, that is not enough

2024-06-15 15:47:05

- reply

for most people, #Nostr provides softer landing to #Bitcoin thinking and onboarding than bitcoin's most valuable feature. it creates a bridge for the most influential and prolific socially oriented user to dive into Bitcoin with less friction and resistance

2024-06-15 10:28:46

@npub1cn4…3vle delivered quite the speach at #btcprague
https://m.primal.net/IlWE.png

2024-06-15 09:06:56

GM #nostr! let's go for day 3 in #BTCPrague
what a beautiful city
https://m.primal.net/IlRy.jpg
https://m.primal.net/IlRz.jpg
https://m.primal.net/IlSC.jpg
https://m.primal.net/IlSA.jpg
https://m.primal.net/IlSD.jpg

2024-06-12 22:22:42

- reply

what is good in Prague tonight? just got to my hotel, was hoping to meet some #nostr people

2024-06-10 07:44:35

- reply

there is an argument to be made about the separation of data storage and client apps and relays. what makes social networking built on #nostr decentralized is precisely that they are modular. each one provides a limited scope of functionality.
if each client app has its own data storage solution, segregated from all others, outside of the protocol, you only own part of your notes in nostr, since migrating to another client could not be straight forward. and we would be back to Twitter.
meaning data storage servers and clients need to agree on a common enough API, so that integration with multiple data storage solutions, and migration is even possible, even a self hosted, or self acquired one. that way, when you migrate from relay to relay, client to client, ALL data in your notes and other stuff will follow you.
it's still early days in #nostr. right now, all those solutions are created and managed outside of the protocol. which means, to me, that integrating into an app is somewhat questionable, and could lead to bricking an app, if that solution doesn't stick.
it's super easy to request a feature, but remember that the challenges to implement such features that we know from other platforms have been solved by segregating your profile to a single network and selling user data to the market.
#Nostr allows for a different approach, and that's what we want from our clients and relays. but it doesn't disallow a centralized app/relay/datastore solution from existing, so we either must be patient in requesting these features, or start providing distributed, cooperative, highly available data hosting solutions that have a good enough API to integrate with #nostr apps and relays