Last Notes
In what world are you living, to call a donation based non-profit foundation a "Coorperation"?
Or do you mean the dependencies?
It’s very cheap. And you could identify npubs who are legit and lower costs even further by not checking them. Its like near 0 cost spam filtering
I can also write a note in notepad++ without registring my phone number.
Can you call people via Delta-chat? Can you have private videocalls?
It is simply a small step forward. Eventually, they can offer different payment options. But one has to start somewhere.
I got Jev to catch about 95% of spam in real time.
I bet I can get to 99%
Not sure how useful this is, but it could be a thing at a relay level I suppose.
I could also have it classify npubs for topics they post on 🤔
Definitly a good donation. Different projects to a more privacy centric world are increasing eachothers usecase.
Signal offers a messenger, that is very easy to opt for and offers very good privacy. It still has some shortcomings. But also offered technical clientside solutions to the privacy community, which became a de facto standard.
A nice little step. But first they would need to accept private payments in one or the other way, so it would actually be a privacy improvement.
Thanks, I guess "fork" and "join" are concepts that apply in the cryptocurrency context, so probably not directly applicable to inkan.
GM
https://blossom.primal.net/ed984acf848cc9b6ca0139c399bc9aea2459f823ad468ad94745c71e3108268e.png
https://blossom.primal.net/4f04186db9a24fccbfef174924711aad258c551cced6d917fe88e10d2dbb4c43.png
I'm not sure what "it" is in this sentence:
"it's cryptographically identifiable"
Also: If others know and agree on the objective time of the revocation, they can *at least* agree that events that are dated subsequent to that revocation time should not be attributed to the revoker.
They can do so regardless of whether or not they agree on how to handle events that are dated between the self-declared start time of the disavowal and the objective time at which the revocation was recorded.
Yes, I quote reposted it soon after, client mingled the url
Now, one of you go offline and then come back in two minutes after more conversation has happened and let's see all seamlessly sync up. 😍
Plebs vs. Zombies just turned one year old last week. 🎈🧟 🎂
Started as a weekend project to find the dead follows quietly rotting in your list, it’s grown since: hunting, scouting, backups, a resurrector for accounts unintentionally (or intentionally) flagged as deleted. It was also starting to show its age, so it needed a facelift. New look top to bottom, smoother remote signer support, and a pile of bugs stomped under the hood.
Reminder, because the branding makes it easy to forget: this is not a game. You’re pointing a signer at your real keys and pruning your actual social graph. A lurker who never posts is not a zombie, and a false positive is sometimes possible if relays don’t cooperate. Read before you purge. Grant immunity to your favorite follows. Always make backups first.
Version 1.0 is live. Happy hunting! 🧟♂️🏹
https://plebsvszombies.cc
https://i.nostr.build/BjK1oNq8oxgIiW0EeRg6Iv.png
To trust a self-declared disavowal, you have to trust the *person* behind the master key.
When somebody retroactively disavows past events that were ostensibly signed on their behalf, then a question arises as to whether that disavowal is honest or not.
This question cannot be decided mechanically or by an algorithm. You have to look at the circumstances of the particular case, and you can only do so to the extent you have access to relevant information.
And an important piece of such information is the *time* at which the person made the disavowal, whether it was made retroactively or not, and, if so, which events fall within that retroactive window.
In many cases, you will simply believe the person who made the disavowal and not attribute the disavowed events to them. You can simply set the inkan client to not show these events, or if you operate a relay you may decide to delete them.
I don't undrestand what's happening on my account, it shows usage as 0 and i've been using it for a while lol
...and we still don't know how large the population of #China really is.
https://youtu.be/D7PuGzvvxHA
Is there an interest in a FOSS version of something like imgproxy (no paywall for features) that is entirely built for AWS Lambdas with a full CloudFront setup via CDK? I had to build one for our needs and there is no real “intellectual property” in it, but I’ll need to clean it up and extract it from a monorepo to be able to open it. If there is, let me know, otherwise I’ll forego the effort. 🫡
50% crash in a month? I mean, anything’s possible, riiiiiight…?
My primary use case is actually just regular nostr users whose keys can get leaked or lost, basically the same reason everyone wants to be able to reset their X password when it gets stolen. It's nothing too specialized, although the system *can* be used for contracting if one wants to.
And just to note this, a revocation primarily protects *the impersonated person*, not the reader of the revocation. So "just ignoring revocations" means basically "the thief gets to keep posting as you to every client that ignores the revocation."
And for revocations to protect anyone, clients have to be able to find them, and they must agree *when* the revocation happened since the revocation is what separates your own old posts from those of the thief.
Day 261 🌅
✨ "Wait."
— Baltasar Gracián
💫 "I let peace be a place I practice, not a prize I postpone."
🙏 Grateful for my dogs in my life. They bring love
https://gratefulday.space
Ugh, dealing with cluster issues again. Don’t deploy on Fridays, a friendly reminder from experience 😅
"Now Dave, try not to get an erection during your prostate exam"
"My names not Dave"...
... "No. That's my name".
GM. Here is an interview with the British foreign secretary about war crimes and the ethnic cleansing in Palestine.
https://youtu.be/xoX-zkB6Ijw
Also our spam problem solved
You could essentially do this on demand too if you have a large cache of notes
I wonder if Jev could be a useful classifier as a nostr algo.
Send it a firehouse of notes, let it classify them by topic / language etc. and you have yourself a ton of custom feeds.
I agree, and inkan gives you exactly that functionality.
When you revoke, you can optionally declare a past time starting at which you "disavow" events signed by the key you are revoking ("I consider this key to have been compromised since September 14, don't trust anything signed by it after that date!").
But the design point is that inkan won't allow you to silently rewrite history that others relied on. Everyone can see both (i) when the revocation was actually recorded on-chain and (ii) the past time from which you disavow.
So third parties get the full picture, i.e. these events were validly signed during the delegation, and the author now disavows them. Clients can either hide disavowed events or show them with a disavowal badge.
There's also a re-ratification mechanism that allows you to rescue your our own legitimate events inside a disavowed window. 👇
#nevent1q…krrt
Ok, never mind, found the information on the site itself. Thanks 🙏🏻
I built some stuff on Jev already :) pretty cool. one is youtube sponsor blocker and ad blocker
What is this site? Sorry, just saw it and was trying to figure out what 21.gifts is and does
That sounds like a whole app unto itself!
No idea, I went to see what the aqstr was, and it told me in the profile
I'm not sure what exactly you mean by "fork" or "join," but inkan's declarations do "join" in the sense that the delegation state at any given time is a function of the total set of past declarations.
But the question whether declarations "fork" or "join" seems in any event orthogonal to the question whether inkan needs consensus. Inkan needs consensus on the relative order of nostr events and revocations. If Bitcoin uses consensus for validating the DAG, that's fine. Inkan just uses the types of consensus it actually needs.
I'm not sure about the "humans" point. Inkan can absolutely issue identities to agents. Neither Bitcoin nor inkan can check that its users are humans.
Regarding the "notary," inkan uses a notary, namely OTS, for the timestamping of nostr events. But a notary is not sufficient for inkan, since a notary can't prove *absence* (e.g "no revocation existed before time T ...").
As for the leak's and revocation's being inherently race that inkan can't eliminate, that's of course true. But a stolen signer can damage only the window between key compromise and revocation. You can also take preventative steps by periodically rotating your signing key preemptively.
Who would have thought? When you bomb a people long enough, 80% want to go somewhere else voluntarily. 🤔
#nevent1q…vpxg
GM! If you have liquid funds on Aqua, you can send them out via LN now, limited to 70k Sats per TX. Got all of my Sats out by doing repeated transactions to my LN address. Let the bank run begin.
https://npub1l5pxvjzhw77h86tu0sml2gxg8jpwxch7fsj6d05n7vuqpq75v34syk4q0n.blossom.band/d17efb735ba5de079935ba4abd0ea0d567e73280c6f50b57a3c1856f402cfcac.png
gm
https://x.com/Rainmaker1973/status/2100438344417321264/video/1
"Y can never spend anything that X signs"
I think that's not quite correct. For example, on Bitcoin, spending something signed by another key is the *normal* case, every spend uses an output that someone else's transaction created.
"We can just trust X's 'created_at' in the revocation event"
If X's self-declared created_at is treated as authoritative, then X can sign a revocation today that's dated last year and retroactively disown a year of events that counterparties relied on. Also, even assuming that X is always honest, the issue about the *discoverability* of X's revocation remains. A party who never *becomes aware* of X's revocation will just keep attributing events signed by Y to X forever.
More generally, revocation is not a private matter between X and someone who has a personal opinion about X's character. The idea is that *every client*, with no trust in anyone, computes the same timeline of delegations and revocations.
"utxo" in this context refers to a "delegation of signing authority from X to Y." Key X can "spend / burn" that output by revoking the delegation, and key Y can "spend / draw on" that output by signing events that are then attributed to X. Order is absolutely crucial because, once a delegation from X to Y has been burned, Y can then no longer draw on that delegation to cause the events signed by Y to be attributed to X.
Just relax and run your node. Wie Markus richtig festgestellt hat, ist das Leben zu kurz, um sich über den Saylorcoin zu streiten.
Are Jeb Bush videos appearing because everyone thinks Jev is Jeb
Algorithm auto-correct?
Guys ITS JEV
Ridin' down the highway. Goin' to a show. Stoppin' on the byways. Playin' rock 'n' roll. Gettin' robbed, gettin' stoned. Gettin' beat up, broken boned
Abstract fluid art with pink and teal colours. #artstr
https://npub10u76a5allqxv9egzqj8wu6y2p7n3fd9c5ncqvwf2gmjnqzeeaqeqs9urt5.blossom.band/443e57afb23384c5c68b6583627b2e3d69d19e8b3b83925462bce30e77b66db1.avif
"when there is no utxo ... in the data"
But the data that inkan is trying to handle *does* have "utxo." There are two competing artifacts that each is cryptographically valid by itself:
1. A revocation declaration R signed by pubkey X saying "X revokes signing authority from Y"
2. A nostr event E signed by pubkey Y
The "unspent transaction output" is the output of the the delegation transaction that occurred earlier, i.e.:
utxo = the delegation of signing authority from X to Y
Now the revocation transaction R invalidates that delegation, i.e. it consumes / burns the utxo.
At the same time, the transaction consisting of the signing by Y of event E tries to draw on that utxo, i.e. it tries to draw on the delegation relationship to cause E to be attributed to X.
So both the revocation and the signing of the nostr event are trying to "spend" the same utxo, one by burning it and the other by drawing on it.
But this type of utxo can only be "drawn on" when it hasn't yet been "burned." So we need to know in which order these transactions occurred.
Classic double-spend.