Nuh 🔻

working on the most minimal decentralized identity I can think of.

https://pkarr.org
https://app.pkarr.org
#pkarr:matrix.org

Public Key

npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz

Profile Code

nprofile1qqsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcq7c3x6

Publishing to

relay.damus.io

relay.primal.net

Author Public Key

npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz

Show more details

Last Notes

2024-12-03 12:38:23 GMT

- reply

You are confusing spam and DDoS. You are also confusing spam and capacity.
Anyway, 10 years from now Mainline will still be going strong, and you won't even know the name of the second best thing.

2024-12-03 04:26:48 GMT

- reply

Interesting, what is your plan? How do you expect say a 100 nodes to serve the entire web, and fend of DDoS and be do all of that cheaply enough that they can keep running forever without churning?

2024-11-30 22:32:02 GMT

- reply

Who is going to build it if not you?

2024-11-30 19:29:47 GMT

- reply

The paper is older than Mainline itself, if it was worth the paper it was printed on, we would have had such DHT by now, Nostr didn't invent WoT... people had many trust networks a decade ago... amounted to nothing, and I bet this will never change.

2024-11-25 14:26:07 GMT

Links should just work. Links with public keys as domains should also just work.
This is apparently controversial, but "whoever show you the link should also help you to find it" defeats the purpose of Links. Links should have exactly ONE way to resolve, and that one way should be socially scalable, meaning it should work regardless of who is sharing it with you or when.
There should be only one variable; either the link is still functional or broken, and it is only broken when the author of it abandons it.
Nostr started as a critique of p2p never working, but it has just as much appetite for chaos and unpredictablity as p2p networks. That is fine and necessary for the social feed usecase, it is absolutely not acceptable nor necessary for resolving URLs, something the web already does perfectly well, and we know how to do it just as well while removing the ICANN dependcy.
#note16u8…aqxz

2024-11-25 13:13:03 GMT

- reply

I am not mixing between the two, I am saying that Nostr does mix between the two.
I actually think you agree with me, you even said that in Nostr looking up a key is always contextual.
My point has always been there is no reason to do this contextual lookups when we could have the no-context lookups.
The reason these two topics are related, is because the illusion that you can find the the data corresponding to any id you seen anywhere is why people don't understand why they really need Pkarr when Nostr exists.
It is really hard to explain to people why URLs that resolve without context matter, when they are not aware that things won't work in Nostr without context, because in their mind there is this vague assumption that Nostr solved global discovery in a decentralised way, so how hard would it be to find nip65 with of a key.
In fact, so far I think Mike Dilger is the only person who both understand why this highly contextual resolution scheme can't work for the generality and scale of the web, and who is also at ease to acknowledge that.
I think you are two focused on "following someone" and I am too focused on "Pubky urls should resolve with as little context as ICANN urls" ... and it is impossible to settle "what ought", only "what is".

2024-11-24 21:51:23 GMT

- reply

I didn't say anything about crucial, I personally like small rooms and discord servers that is fine. But definitely the claim that you can do with Nostr what you can do with centralised search indexes Without the centralisation is a prevalent and unchallenged.
Mainline approach only works if your query is a hash, and only a hash. And the data is small enough and the nodes are numerous enough that you can keep publishing the data cheaply with redundancy factor.
For general purpose search, the query can't be just a hash (if it is just use Mainline I guess) and the data is usually too large for it to be cheap to store and serve (which means less nodes).
So you can't shard the data, and even if you can there is too much of it.
Pkarr idea is to use Mainline for the absolute minimum, and pray that is not too much, and cache at every possible layer to reduce the load on the public common, otherwise we have unrealistic expectations

2024-11-24 21:12:38 GMT

- reply

I am talking about global search... of course I understand hyperlinks and rss feeds.
But I'd you want to go to a client and see or find most of the data you are looking for, that is simply means you need someone to have crawled all that data and built an index for it.
Just reversing crawling by submitting data to relays doesn't change anything. The costs are roughly the same, and with more cost you get less options so your decentralisation claims go out of the window.
I never said you can't make millions of indexers that index small sections of the Internet.
I am not assuming that you say global discovery is decentralizable but plenty of people insist that it is and refuse to face reality because it is not as exciting as claiming that we finally did to search what Satoshi did to double spending... we didn't, physics still apply.

2024-11-24 20:52:59 GMT

- reply

No no no, I am not "claiming that if DHTs are used correctly and perfectly will always work", I have shared working code countless times and you just refuse to try it at all, in fact you keep saying stuff like "peers" which means that you refuse to even listen when I say over and over that Bittorrent seeding experience is not a minimal test of DHTs capability.
On the other hand, you don't acknowledge that the Outbox model doesn't have a neat solution even in theory to when we I am trying to look up something from a cold start, with no shared relays or a well connected social graph.
I don't know how is it that I am offering a working code with much less requirement (barely anything other than a key and UDP connection), but you talk as if these are two equally unproven and prune to error approaches.
I apologise if I seemed dishonest. But I also reject this false equivalence, and it strikes me as not reasonable.

2024-11-24 17:09:08 GMT

- reply

No, the key you use to identify users has consequences, because when it is secp you are stuck with this daisy chain discovery that has no proof that it can work at scale with enough reliability and performance.
If you identify your friends as ed25519 keys, then you can get the DHT's performance and reliability, and then you can put a secp key in your records and use that to sign Nostr events you put on relay to use as one of your outreach methods, but you don't get stuck to how Nostr handles what DNS solved since the web started.
On the other hand, if you identify your friends ad ed25519 keys... you don't have to inherent ANY of the architectural choices that yours truly makes for storing data or otherwise.

2024-11-24 15:03:04 GMT

- reply

see how complicated all of this is? the Outbox model is as complicated as it is and often not supported because it's complexity, exactly because it was an after thought and is in the shadow of handwavy promises of global discoverability.
I claim, that if your purpose is to find the data of a user by their key without censorship, and if you were not deluded by global discoverability, you would have arrived at something like https://pkarr.org, because you would have the privilege of thinking this from first principles.
It is only the fake promise of global discoverability that makes the existing complexity and unreliability of the Outbox model seem tolerable.

2024-11-24 13:37:18 GMT

- reply

Just because the delivery mechanism is 1-to-1 doesn't mean it is impossible to be 1 to many.
But, if you are interested in reality whatsoever, you have to acknowledge that many-to-many is an intractable problem and anyone says otherwise wither dishonest or didn't care to think it through.
Nostr itself started with this realisation (watching p2p systems) and relays are intended to be a layer with fewer nodes so that data can converge before diverging.
You can call that sufficiently decentralised, but it is not any different from Bluesky claiming that there can be tens of relays. Nostr didn't yet show how is there going to be tens of relays offering that global view to everyone when "everyone" means 100s of millions.
so my point stands, global discoverability is impossible to make decentralised, the best you can do is give up on either decentralisation or global view.
If you give up on global view, then you are just talking about rooms, you call them relays, but they are just big rooms.
This is not a criticism of Nostr or Bluesky, it is just an attempt of breaking the deliberate tendency to ignore physics when talking about global discovery... people just decide that the impossible is possible and refuse to engage with reality ... not good.

2024-11-06 14:52:53 GMT

- reply

Pkarr was used by 2 external teams before it was used internally in pubky, in fact before the name pubky was chosen.
Good ideas don't need much advertisement, but they definitely deserve advocacy. If you know you have a good idea, reach out to smart people and tell them about it.
I get paid whether or not I talk about my work here... I just enjoy talking about it for anyone who would listen.
If you don't want people to hear about your work, work on something different.

2024-11-06 07:29:33 GMT

- reply

You are failing miserably, I know smart harsh criticism when I see it, all you are saying is fuck you, that is not a truth that hurts... get gud.

2024-11-05 21:25:13 GMT

- reply

you seem like a happy person :)

2024-11-05 21:23:53 GMT

- reply

Is this our job though spending our time begging on Nips repo?
we built Pkarr, we showed it to everyone for many months, and we're told it was unnecessary.
Pkarr is still there and keeps getting better. Anyone is welcome to use it.
And for strong consistency, I meant it in the Write sense, meaning, in Nostr you can't do lists or counters safely, on Homeservers it is easy.
Another way to say it is: single writer. Think how LMDB offers great transactional safety because it just rejects lock-free multiwriter paradigm.
And if you believe that most users read way more often than write that is a reasonable tradeoff (maybe slower writes or occasionally unavailable writes) for the sake of having stuff like consistent pagination and exclusion checks and maybe versioning.
Saying that that doesn't scale is like saying having only one Git remote doesn't scale, of course it does.

2024-11-05 20:40:55 GMT

- reply

First of all, Pkarr was shared with Nostr folks especially Fiatjaf from day one, the reaction was always either Nostr doesn't need it or we can't change the Identity now it is too late.
Secondly if you are willing to make a breaking change like Pkarr as the root identity, then might as well reconsider other unfortunate parts of Nostr that are bundled with the discovery layer for no reason, most importantly why would we use websockets and Nostr events as base API instead of HTTP verbs, headers, and semantics? just because Nostr made that bad decision? Why not build a datastore like WebDav and then advertise that event (PUT/DELETE) on Nostr relays?
Well, pubky core only engages with Pkarr and data stores. And it doesn't tackle discovery so Nostr can be that for Pubky or not.
But note that Pubky didn't take away anything from Nostr, anymore than Blossom takes away from Nostr, if anything wr just decided to use the tried and tested tech of web servers.

2024-11-03 10:49:25 GMT

- reply

Pubky is definitely inspired by RemoteStorage and the general Unhosted.org philosophy. I believe we do things that RemoteStorage does not do though. Most importantly; Pkarr instead of web fingers, and the paginated listing API making Pubky an ordered key value store, not just a filesystem.

2024-11-03 07:51:16 GMT

I want to make pubky so good that no indiehacker can be bothered setting up a backend to validate an idea.
They would tell early adoptors; Just sign in with your pubky and come with your own backend, and that wouldn't be too much to ask. Maybe even attractive to users who know that their data won't disappear if the developer got distracted by another side project.

2024-11-01 16:41:57 GMT

This is a popular point: we can make our own DHT.
Yes yes you can, we literally used Hyperswarm which was a special DHT because Mainline didn't have good Holepunching. We switched because after YEARS it is still TINY. like 3 orders of magnitude tiny.
You can't simply bootstrap censorship resistance, in fact it is a miracle we have millions of DHT nodes in the first place, and we ONLY have it, because there is an organic incentive to run a node (Bittorrent clients and pirating).
What is harder to do? rebootstrap millions of DHT nodes? or rebootstrap convincing tens of thousands of Nostr users to slowly migrate to Ed25519 keys?
That being said, I personally don't think we should convince Nostr to adopt Pkarr. The only goal should be to make the facts clear.
#note1cua…jv4c

2024-11-01 14:46:45 GMT

- reply

The point isn't control. Having short names complicates things and makes it much harder to be permissionless and censorship resistance. Because it requires some mechanism to decide who owns what, and that boils down to either central authority, or a consortium, or miners of a block chain.
So, no, not only is Pkarr not like zeronet, we don't even encourage vanity addresses, we want keys to be like phone numbers, you own it, people alias it, and everyone is sovereign and happy.

2024-11-01 13:59:57 GMT

- reply

Yes indeed public keys can be generated by anyone anytime without any infrastructure dependency. Applies to Npubs and Pkarr, because the former is Secp and the later is just Ed25519

2024-11-01 11:52:34 GMT

- reply

There aren't millions of pubky nodes, pubky has no concept of nodes. Pubky uses pkarr.org, which is just a spec for using Mainline (Bittorrent) DHT and especially BEP0044 to publish DNS packets.
According to Pkarr, public keys ARE the TLD. Controversial design decision I know, but I stand by it. So no plans to beg ICANN for a TLD. Gnunet begged for .gnu and ICANN refused. We need them even less, given that we use 52 characters TLDs, there will never be a collision with ICANN tlds.

2024-10-30 16:27:50 GMT

- reply

If you think this is a sufficiently censorship resistant alternative to millions of self organizing nodes, so be it, you know your threat model best.
Pkarr is a bet on the biggest and the most battle tested network, that is old enough that is most likely to survive for at least as many years.

2024-10-30 15:19:50 GMT

- reply

which 3 or 4 relays should I query to know what are your preferred servers? how can I possibly know which relays did you post your list on?
wouldn't that by default force us all to post and read from the same 3/4 relays to have reliable resolution? wouldn't that make them target? and what happen when they censor you or go offline? where do I go to find you now?
if you try to solve this, you will end up reinventing DHTs, but you have ZERO chance of making a DHT even 1% of the size of Mainline.
So your options are:
1. use Mainline DHT
2. make a worse more vulnerable version of Mainline DHT and use that instead.

2024-10-30 10:06:08 GMT

- reply

Nodes will rate limit them, nodes that don't have rate limits will keep dropping older data.
It is a sloppy network, you should never expect the DHT to give you perfect reliability.
But just like you don't query the DNS root servers directly, you don't need to query the DHT directly, you can use relays with bigger cashes and more robust rate limiting and only rely on the DHT for things you haven't seen before.
obviously that also means that you shouldn't update your Pkarr too often, because long TTL is a big part of the reliability and scalability

2024-10-30 09:55:21 GMT

- reply

Miguel already created one a while back. I think it is against our vision where users don't see keys much, instead using their local aliases. https://github.com/miguelmedeiros/pkarr-vanity-keys

2024-10-30 06:36:13 GMT

- reply

All open source software has leadership whether you recognise it or not.
The question is, is this leadership more of a risk than it is a benefit.
An anarchic leadership reduces the risk of things changing too fast that only large corporations can keep up.
But it also increases the risk of paralysis and implementing ideas that almost everyone agrees is best, because no one has the power to pursue anything decisively.
We think our way of doing things allowed us to design things from first principles and have a very minimalist and well reasoned architecture.
If you listen to us more often, you might be convinced that we are very protective of the simplicity of the core protocol, pushing most of complexity to higher layers or optional APIs, exactly because we want to build one foundational layer on top of another, as opposed to spontaneous house of cards.

2024-10-29 06:31:40 GMT

- reply

Happy yo answer your questions.
But the simplest and closest analogy is DNS and WebDav.
Pkarr is a censorship resistant DNS.
Our Homeservers are a nicer WebDav, in many ways, none of which are revolutionary or unfamiliar to web developers.
Some aspects might feel disgusting to Nostr devs, like the fact that data is not signed at client side (not at the protocol level) but we think that is a good thing as it allows for better key management and usage of tried and tested alternatives like good old sessions with cookies.
you can however ignore the homeserver and just put your npub in Pkarr. we just believe that homeservers allows decades of web development to be put to better use.
As you can tell, Pubky core doesn't answer the discovery question, unlike Nostr which starts from discovery then tries to bend relays to be hosting providers with Outbox model.
For discovery we think crawlers and indexers are the normal solution, just like they were for the early web.
But there are plenty of apps that can be built without discovery, and our strategy is to spend the least amount of complexity to achieve the most leverage, before moving to more complex and frankly harder problems in principle (like censorship resistant global search).

2024-10-27 17:43:50 GMT

- reply

I do, it is mostly my fault 😀 .
Happy to answer questions.

2024-10-17 23:32:45 GMT

- reply

If anyone is interested, I am working on custom reqwest::Resolve and rustls::CertificateVerifier that allows reqwest to make https calls to Pkarr (pkarr.org), so anything that has TLD that is an ed25519 key, can have secure connection like ICANN TLDs.
Unfortunately, it will take forever for browsers to adopt that if ever, so a hack is necessary in the meantime.

2024-10-17 23:28:49 GMT

- reply

I don't think it will work in browsers, I wish I was wrong though

2024-10-15 06:33:33 GMT

We are entering the era of "zionism started with good intentions but lost its way".
That is utter bullshit, of course. zionists never had intentions other than ethnic supremacy through terror and genocide.
But at least delusions about the past are less harmful than delusions about the present.

2024-10-06 10:15:31 GMT

- reply

What is NWC?

2024-09-20 10:15:00 GMT

You can make HTTPs (TLS) request to a Pkarr top level domain, without relying on ICANN at all.
(I know because I tried it)

2024-09-12 17:17:05 GMT

- reply

in the git repo there is section about republishing.
but long story short, service providers are the ones republishing their users records.
there are more opportunities but that is the fail safe approach.
the problem is, relays are not actual service providers so that paradigm is not a perfect fit, but they can implement whatever criteria they want, including dropping keys that no one is asking for anymore.
in a proper sustainable setup, servers know what accounts they have :)

2024-09-02 09:40:57 GMT

Nostr clients that don't highlight Nips and add a Hyperlink to read more, why are you like that?

2024-08-27 06:28:09 GMT

- reply

But that's the point, this regulation kills any competition, unless the competition enforces e2ee like you said, and then most users will stay away because they will keep losing their encryption keys.

2024-08-27 05:35:02 GMT

- reply

That is not feasible for apps where data is more valuable than ephemeral chat.
imagine if Google Drive started encrypting by default, the amount of people that will lose their data (when they never asked for encryption in the first place) will kill the app.

2024-08-27 05:31:00 GMT

- reply

They can and are trying so hard to make that illegal too, it is not like existing laws aren't as equally absurd.

2024-08-27 05:30:03 GMT

- reply

What if I am running extremely tiny business that just happens to serve a very distributed client base? Are those businesses just unfeasible legally anymore?
Of course not, people will keep doing that, but because they are small they are not a target.
I hate this whole thing it is depressing.

2024-08-25 17:45:06 GMT

I am a maxi too, but I would bet money that bitcoiners on social media are on average more stupid than the general public. And I am only talking about critical thinking, if we are going to consider emotional or social intelligence, then the situation is dire.
#note18x7…zn6x

2024-08-25 12:24:26 GMT

- reply

Not that defeats the purpose of avoiding vendor lock in, as I said, you might like to play with https://pkarr.org and see what it can offer.

2024-08-25 12:22:15 GMT

- reply

Figured. I can't cross to the Greek Islands, but if you can cross to Kaş I can visit, Always happy for an excuse to go there.

2024-08-25 12:18:09 GMT

- reply

Public keys can be made into sovereign TLDs so the server can always resolve the homeserver of a Public key (and more) just like you resolve the IP of a domain.
Check pkarr.org

2024-08-25 09:01:32 GMT

- reply

Also, nostr relays talk to each others, just not as a part of the protocol, but at least all strfry relays have the option to gossip and sync with each other efficiently

2024-08-25 09:00:19 GMT

- reply

I am sympathetic to the idea that servers shouldn't talk to each other, but if you do trust your homeserver, wouldn't it talking to foreign servers on your behalf, at least hide your ip among other things?
Not sure what leakage are you referring to and what is the threat model.

2024-08-25 07:56:54 GMT

- reply

Not sure is that a criticism because it is not P2P? Or because it isn't a centralized server like Signal.
I enjoy Signal too fwiw.
I usually don't care much about leaking who I am talking to and when, vs the content of conversations.
But I understand the concern.

2024-08-25 07:42:14 GMT

Matrix is amazing, the only downside is that it doesn't use self sovereign identity, but it should be easy to fix that. Some day. #note1zat…htjh

2024-08-25 07:23:14 GMT

- reply

Not any time soon, but hey, if you found yourself crossing the Aegean to Turkey, would love to meet.

2024-08-25 07:16:20 GMT

- reply

safe trip, we can pick it up later in a more convenient way, let me know if you want to schedule a call, otherwise I will try to respond to your concerns later when you have time to share all your thoughts

2024-08-25 07:04:47 GMT

Counter point, you can trust whatever you choose to trust, including eating at restaurants without testing the food for poison, and of course custodial zaps.
(this is not a dunk quote, a much longer detailed reply is inside)
#note1tka…ue5e

2024-08-25 07:01:44 GMT

- reply

I thought you supported key delegation, do you think signing a delegation to a key held by the server is some kind of a sin now?
And no, that is not the current trust model, the current trust model is : ICANN won't take your digital identity.
If we solve that (granted by publishing signed announcements) then we actually solve the vendor lock-in and deplatforming.
Now some applications can't tolerate any delegation of trust for sure and for these apps, I absolutely support complex stuff like e2ee messaging where you can't share keys with your server.
But saying that nothing can work with delegation at all is not honest, if people are OK with using custodial LN, it would be insane to say that trusting a hosting provider to not modify your shitpost or that that would be unacceptable risk.
Finally if you don't accept delegation at all, then you are forcing users to a maximalist trust model that they don't want, and forcing them to deal with the risk of losing their keys for that choice you are forcing on them.
If you do accept delegation then we can argue whether it is safer and more convenient to trust the server with the sub keys or should we only trust clients in our hands, as if these can't be compromised and users get sloppy with.
If you accept delegation, and you accept that being able to fire misbehaving holders of keys, then we are arguing details like whether servers should be trusted to delegate some temporary trust to, or you should limit that to machines you own.
Either way, the moment you accept delegation, it is not up to you, users will do both.
So again, the choice is either key delegation is acceptable or not, once you accept it, then we can discuss why when and where should data still be signed at all, and when it doesn't matter much.
But long story short, if I already delegated signing to an nsecbunker, and that server is the same as my Outbox relay, then people reading from that relay directly don't actually need to verify anything, other than that this relay is still the outbox and is still trusted, verifying signatures would be entirely superfluous and redundant since you already have TLS for MITM prevention.
You can argue then, that we need signed data so that clients don't have to trust intermediary relays, and that is true especially if your client doesn't implicitly trust a hard-coded relay.
if you run your own relay and you trust it, or trust a friend's relay, or simply trust the client so you are OK with trusting the hard-coded relay in it ( because clients can fake things too) then you don't need to verify anything either.
you trust the client, the client trusts the relay and the relay connected directly to the "outbox" relays crawling data . not much need for signed data.
So the actual place where you need signed data, is when you need to gossip events with people you don't trust much beyond not spamming you, basically Torrent/Bitcoin/Git like situations. And for that, you should absolutely use signed roots of the merkle trees of users data, but notice that even then, you are better off still delegating that work to the server so it can offer more features like strong consistency.
You can always sign data on client side when appropriate, nothing prevents you from hosting signed events on a web server, but the argument is, when that is not needed/overkill/ or worse prevents good sustainable key management, then it shouldn't be the default.
I hope you can see the value of fixing DNS with Pkarr, even if we still commit the sin of not signing all blobs including car pics with the root key risking losing it
Anyway, always nice to argue this stuff, enjoy your day.

2024-08-25 06:34:26 GMT

- reply

No, they can delegate, web hosting have been a thing since forever.
are we going to pretend we can't trust servers that we are already in a trust relationship with to not fake our data?
Not everything needs to be that extreme, life is built on trust, as long as I can always fire a misbehaving server.

2024-08-24 08:04:04 GMT

- reply

I am not sure they understand it. If they did, they would have realized that something like Pkarr + any normal HTTPS server satisfies the vast majority of the web usecases.
The only reason to sign data beyond that, is if you are publishing something worthy of gossip, like Torrent or Git repo.
You don't need a witness when there is only two parties involved, the client and the authority.
But instead people take about signing data in a very religious way. Users don't need to sign every damn thing, especially when the price of that is losing your identity every time you lose a signing key.

2024-08-24 05:47:21 GMT

I desperately need people to understand that data doesn't need to be signed (be self-authenticated) if you download it from the authoritative source and you trust the DNS and e2ee between you.
If you don't have gossip infrastructure (and demand) in place, signed data is dead weight and larping.

2024-08-17 09:00:17 GMT

- reply

The one thing that never happened in these lands, in 1000s of years of shifting powers, is mercy for falling elites. This is not Ireland, this is not South Africa, this is not Germany.
Minorities may survive here, but the defeated masters never live to try again.

2024-08-17 08:51:49 GMT

- reply

They are scared, that's why they keep repeating "we are not going anywhere" like a self-soothing lullaby.
This is why they keep committing more brutal crimes against humanity, like tensing their feet on the landmine to make sure it doesn't relax too much.
Their demise is inevitable, and deserved.

2024-08-17 08:47:43 GMT

zionists, by insisting on becoming a minority rulers in Mesopotamia, are like a man who voluntarily stepped on a land mine, they can't left their leg without losing it, but they also know their leg will eventually give.

2024-08-16 06:14:43 GMT

"This genocide went for so long, that it lasted full pregnancies, and killed the mother and her new born children too."
zionism evil is unmatched, even by the middle east criteria and that is really something.
https://twitter.com/academic_la/status/1824286723976962529#m

2024-08-16 00:10:46 GMT

zionists continue, with full institutional backing, to steal people's land, and kill anyone who resists, then they will complain when that backfires later.
This is why you shouldn't condemn any violence against zionists, they deserve it
https://xcancel.com/IhabHassane/status/1824058968701915491#m

2024-08-15 23:55:18 GMT

zionism is going to the remnants of the community you ethnically cleansed, and currently militarily occupy, and started burning their homes door to door while they are in it hoping to burn families alive, as they have done before.
https://xcancel.com/NTarnopolsky/status/1824152750256758961#m

2024-08-15 07:04:17 GMT

- reply

If you bend backwards to assume the best I people, then "liberal zionists" are not evil trying to maintain the public image of genocide, but just entirely delusional and out of touch with their society's nature or at least present and future, but then they still deserve ridicule and shame.

2024-08-15 07:00:44 GMT

- reply

Interesting framing, which isn't far fetched, but more importantly the internal politics became so deranged that he has to sound as deranged or he will lose to even more deranged politicians.
This is why I say the charade of liberal zionism is never happening again, despite people living in denial

2024-08-15 04:06:19 GMT

zionists are trying to distance themselves from their own atrocities, pretending that the problem is in their current government, not in zionism. They will never get any other sort of government ever again.
https://twitter.com/academic_la/status/1823788049563795683#m

2024-08-09 11:09:28 GMT

What went wrong, so that a free library, is still richer browsing experience than the internet?

2024-08-05 15:23:59 GMT

"It might be justified and moral to cause 2 million gazing to die of hunger but the world wouldn't let us" - zionists
https://www.timesofisrael.com/liveblog_entry/smotrich-might-be-justified-and-moral-to-cause-2-million-gazans-to-die-of-hunger-but-world-wont-let-us/

2024-08-04 19:59:39 GMT

- reply

I don't know either, that's why am asking, I think all this compliance shit is vague on purpose, so maybe the question s futile.

2024-08-04 17:32:52 GMT

- reply

Would the illegal websites issue be less problematic if the encryption is end to end?

2024-07-30 08:27:43 GMT

https://nostrcheck.me/media/930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9/6d16f3b1e23526a50e1e726af4974e4fc1f7babe82c1ce456e5b53b40f5f6eac.webp

2024-07-29 12:33:54 GMT

- reply

dns is not the issue, not even a little, running servers from home is a solved problem, http tunneling is perfect, the real unavoidable problem is that maintaining servers suck and no one wants to do it.
in fact the very idea of Nostr was based on that thesis as opposed to the p2p thesis.

2024-07-26 12:05:13 GMT

- reply

"advertise" where? where should I advertise for everyone to find me? damus relay?

2024-07-26 06:51:53 GMT

- reply

The main argument for proxies then are that personal relays might have less capacity and/or availability than proxies that are basically trustless caches or CDNs at this scenario

2024-07-21 09:03:13 GMT

Driven and honest >>>>> Expert and correct.
As the former can obtain expertise and correct their wrongs, but without drive nothing gets done, and without honesty you can't even face the fact that nothing is getting done let alone efficiently or wisely or in good taste.

2024-07-20 07:33:10 GMT

- reply

they don't use ION anymore they use Pkarr but encode a DID in it, because of course they would

2024-07-20 07:29:44 GMT

- reply

you are too focused on ports or web servers. A web server is just an executable, and opening ports or using free http tunneling service is the easiest part about hosting your own data. And the simplicity you win using holepunching , you lose on the other side because it doesn't work in browsers, unless you then use a relay, but then that is what an http tunneling service is.
finally, people don't want to host their own data, not because they physically can't open a port, but because they then need to manage electricity, connectivity, handle any bugs, upgrades, database migrations, backups etc.
sure for popular stuff like movies on Bittorrent it is magical, but if you are going to be mostly the only provider of the data, might as well just use a hosting service you trust. otherwise you are just pretending.

2024-07-20 07:22:05 GMT

- reply

you are thinking of ION, that is mostly now a abandoned, they made a new DID called did:dht based on https://Pkarr.org

2024-07-14 09:07:12 GMT

Watching Americans censor themselves so hard, and wisely so, makes me wonder if the USG only speaks softly because they are carrying a really big stick, while ruthless authoritarian regimes are just compensating for a precarious control over their societies.

2024-07-10 05:52:49 GMT

"Stop Antisemitism" abused that term so much that their account is nothing but a constant signaling of how ineffective that accusation became, absolutely no one gives a fuck and rightly so.

2024-07-09 14:06:00 GMT

- reply

No words matter, when you call something Nostr identity or Bitcoin identity for that matter, you are implying that there is an added value to the bare keypair.
So when you call it Nostr identity, you can't then say it is not dependent on Nostr relays, since without Nostr relays, there is no added value beyond just being a keypair.
And when you say they scale to billions of users, that is meaningless, it is like saying bitcoin can scale to billions of users since you can make billions of addresses.
Again addresses and keypairs are meaningless alone, they get 100% of their features from elsewhere, they gain identity ONLY when there is an attached social graph, they gain value ONLY when they author data or transactions, etc.

2024-07-09 11:31:34 GMT

- reply

You are calling a keypair an identity, because eventually there will be web standards that Nostr refuse to use, but you insist to call that Nostr still.
That is ridiculous, why do you call it Nostr and not just Bitcoin identity then?

2024-07-09 08:56:02 GMT

Openvibe is great, ot definitely favors Bluesky and Mastodon though, since Nostr has no key delegation, so if the -closed source- app leaks your keys, you are screwed.

2024-07-09 08:48:34 GMT

- reply

As I said, it is a separate identity ONLY if you consider npubs ... just pubs lol. The only thing that makes npubs separate from bitcoin any secp is that they have attached data that can only be found on relays. And since Nostr has no proper way to map keys to relays, running your own relay after the popular ones die is useless, all because nostr devs refuse to be pragmatic and realize DNS existed for a reason.
And as you say, delegation is being deprecated and it never took off, and no actual discussion about it is happening other than nsecbunker.
And this unique value proposition is nonsense, any DID or Pkarr or any domain name with DNSSec can specify a secp key and gain these advantages, while still being resolvable in the first place.

2024-07-09 08:39:25 GMT

Hello from Openvibe!

2024-07-07 13:47:40 GMT

This is not true at all
1. Nostr identity is impossible to separate from Nostr relays, there is no other working network to find information about a key, not even simple stuff like Signal username or Matrix ID.
2. Even if you mean identity as in Auth mechanism to centralized servers, that is basically LNURL auth then and it sucks.
3. Without delegation, these keys won't fuckin last, billions of users is a pipe dream, it is a struggle to even get software engineers to secure active keys for a month straight!
That being said, I agree in general that we can give sovereign identity to billions of users, much easier than decentralizing real-time social applications. I just don't think Nostr keys are good enough.
#note14ct…dkc6

2024-07-07 13:37:05 GMT

I take this back, if the username is TLD (Pkarr) you don't need TXT.
TXT is still useful for information that isn't about servers, for example PGP keys, even if these keys are valid pkarr tld since if they are ed25519, it is still not appropriate to put it in SRV.
#note15ym…lv40

2024-06-27 11:04:25 GMT

- reply

you?

2024-06-23 13:05:16 GMT

Very few people understand the value of hashes and signatures in Nostr, they think it is sovereignty thing, it is not, it is lack of authority thing. If nostr had an authoritative strongly consistent server for each user, hashes and signatures would be limited to gossip through 3rd parties, but because there isn't any authoritative servers (some try to add that in retrospect with outbox model) all parties are 3rd parties.
Nostr is not trustless from the user's point of view, no user ever checked if the content of the post they are reading actually match the hash or correctly signed, that is larping.
self authenticated data is an efficiency optimization, NOT security feature.

2024-06-18 11:42:47 GMT

- reply

There is no need for a NIP, if Nostr devs can't be bothered to do what Fiatjaf wants, ain't no chance anyone will care to integrate a whole incompatible identity (npubs are entirely different curve than ed25519).
the only viable solution is to start over :)

2024-06-18 11:37:18 GMT

Again, that is like saying you can't spec DNS ... you can, and you absolutely should for there to be web at all... at all
#note1ft9…2fqy

2024-06-18 04:32:20 GMT

this is like saying "web servers go down all the time, so why bother with DNS"
#note1397…r444

2024-06-18 04:28:22 GMT

imagine if finding the ip address of a domain was a philosophy not a spec... please don't build a web3.0 if it is going to suck at the most basic functions of web1.0
#note16ma…9fts

2024-06-17 15:31:07 GMT

do you want to have this mind-numbing argument with everyone, or do you want URLs to work? use pkarr.org
#note1z5t…muqw

2024-06-17 13:33:15 GMT

sigh... guys, if we are going to reinvent the web, we better start by not failing at what DNS has been doing reliably before we were born. and yes I will post the link again pkarr.org
#note1cwl…2suw

2024-06-09 05:30:17 GMT

Any sufficiently advanced digital identity is indistinguishable from domain names.

2024-06-02 16:48:36 GMT

- reply

not arguing against you, but DMs have a super power; it is easy to keep censorship resistant, because it is a small world. all you need is a protocol, servers and sovereign identifiers to migrate between servers while keeping your ids.
another superpower; people actually tolerate when chat history is lost due to losing encryption keys.
I would say we should focus on DMs more than social since it is easier to get done, but Matrix is good enough so not very urgent to reinvent

2024-05-26 14:38:00 GMT

- reply

1. unbounded state make me nervous, but I guess if the Mint gets a fee from every minting operation, it can adjust the fee to cover the cost of storage.
2. do you think mints should use OTS in case someone contests that a secret was spent?

2024-05-26 14:08:01 GMT

- reply

reading the spec, do mints need to keep all "spent" secrets forever?
also, is there a way for a 3rd party to audit whether or not a secret was spent?

2024-05-21 09:52:57 GMT

- reply

you are mistaken, Nostr isn't better than Mastodon because it offers unique storage solution. You can backup your Mastodon posts just as well, the difference is Mastodon server owns your identifier, so even if you upload all your posts to your own Mastodon server, you lose your identity (and thus followers).
Nostr commits posts to your public key, and demands that your followers look for you using that key.
of course, it doesn't answer how should your followers find you except by a coincidence of publishing and reading from the same relays.
Pkarr.org offers an answer to that question, but it is not compatible with Nostr keys unfortunately

2024-05-21 05:11:52 GMT

- reply

money laundering