Keet is an overdocumented inefficient platform. And it will be fine if their marketing wouldnt try so hard to sell you their shit as an "open protocol".

work with the fed is a bit of a stretch... you work with fed by paying taxes... at least the fed is paying tether on their treasuries and buying bitcoin with 10% of profits which is similar to all us plebs just working and savings in sats.

but yet I get your point.

time will tell. We need something p2p and out of reach from the feds.

GM

true keet is not open source yet. holepunch is but you are correct keet is still not. its a ? if they share your data. it would be wild if they turned around and did the opposite of what they say. But its still not open.

when that does happen, then it will be the best Private DM on the block in my opinion.

Are there any research into how much of estimated amount of money laundering the banks actually uncover with their insane KYC policies? Probably hard to get specific numbers but there must be some research into this?

Nostr is really good at things you want everyone to see, specially public square.

Nostr is not good at private things, like private group chat replacement or DMs.

And that's ok.

Focus on the things you are good at.

keet.io is good at Private DMs ... and its getting better.

GN! Love you guys🫂

i identify as a mosquito hater

nobody hates them more than me

Watching #Uruguay versus #Brazil 🇺🇾🇧🇷 #CopaAmerica2024 ⚽🥂

The most retarded man on Earth is going to sue me because his precious (shitty) cartoon character avatar is on the Fediverse.

UX should be perfected by the people that willingly want to use a tool, not the potential mass adoption normies or the proverbial grandma.

There is a whole beautiful world out there outside of our Bitcoin echo chamber, it's not all zombies

We should want to attract artists and other content creators but instead we just cope and say it's fine with like 40 bitcoiners repeating mantras

And it basically doesn't work, most clients cannot find notes that aren't on the big relays, which is just Twitter all over again but with more steps and worse UX

Sure. But besides reproducible builds it's impossible to know if the build is not manipulating the source code. So you got to trust the dev and the build environment

It will be interesting to see how it all plays out.

I'd definitely value a dev attesting that they reviewed all the code added to Sparrow Wallet in a release and Craig Raw isn't obviously rugging everyone. I'd want to zap that.

I'm not suggesting you should as it would shift your focus from building zap.store into QAing apps. Using a f-driod type issuer of releases would prevent the developers from issuing malicious binaries for non-reproducible builds but enable the issuer to do so. I don't think the incentives are there for anyone to take on that role.

The nature of the trust attestations and how they are interperted is the tricky bit. Probably much easier to critise than design.

zap.store shouldn't be listed as a maintainer of a project because it doesn't make decisions about what code is or isn't included in a release. However, if it decided to take on a role like f-driod, it could issue a app profile for some apps, review releases produced by the project to check for undeclared trackers and malicious code, build from source and issue their own releases for an app.

Curator sounds great! In reality, most applications aren't reproducible and we are trusting the issuer that they built from source and didn't introduce any vunerabilities in the process. In fact, most applications aren't opensources so we are trusting the issuer even more.

Having trust atestations against app profiles and pubkeys that issue them are the most important and useful sort. Curator is a really good choice of word to describe this.

I thought about this one as it becomes very difficult to add later as we are building a bazzar rather than a cathedral. The incentives won't be there to add it later.

Without this feature most app teams will create a keypair for the app and share the key between maintainers. This will build up trust and an install base. They won't be incentivised to abandon threre existing pubkey which has built up trust and an install base. They won't have a mechanism to make it easy for users to switch to the new model. And unless 90% of the client support it they will degrade the upgrade experience for a proportiom of their users.

Clients won't be incentivised to add support because 1) there client is working 2) they are busy with other things 3) existing app teams aren't asking for it becuae of the above incentives 4) they are waiting for other clients to add support first

Another point is that in many instances I may trust an app profile issued by a zap.store or f-driod.more than one from the developers as I may trust there processes to review apps for malicious activity and tracking more than a set of maintainers that aren't in my web of trust.

Different app profiles for the same application can be a good thing.

I see the maintainer role as quite different to the contributor role. Maintainers decide which changes get applied to an application and make it into each release whereas contributors propose and / or code the changes. Often maintainers also review for quality but this is also sometimes left to contributors theough peer review.

The fabrication argument applies to the contributiom rather than maintainership.

In my above example the 3 maintainers could decide to create a key pair specifically for releases and share it amoung one another. It could issue the app profile event and each release. This seems to make the most sense if users are going to subscribe to a single app profile per application for releases.

What happens if one of the maintainers moves on? may be there is a falling out or they start working on the closed-source competitor. They will still know the signing key.

If however, app profiles supported maintainers each of them could create their own app profile from their existing pubkey, leveraging their own reputation, and include the others as maintainers. excluding the maintainers field, the app profile for this group would be the most recent one submitted by any of them. Any releases issued would be on behalf of the group. The membership of this group can evolve.

This is the best case I can make for adding a maintainers field.

I would prefer to follow an app profile published by a group of specific pubkeys with their own reputation who claim to maintain an app than a single pubkey who's ownership is opaque.

Honestly, cockroaches eat feces and spread disease, and butterflies are pollinators. I don’t think it’s a very good comparison lol.

"If you kill a cockroach you are a hero, if you kill a butterfly, you are evil. Morals have aesthetic criteria." ― Friedrich Nietzsche

I agree but it is also sometimes useful to have a application signing key.

The common way of signing a release is to sign a checksum file which lists all of the related binaries hashes. That is essentially what the the nip51 event does although it doesn't include the actual hash, but rather the id of each event that contains the hash. This makes it harder to find release events that include a specific binary because there may be many nip94 events referencing the same file. We need to query for nip94 events for the hash first and then find releases that reference those. I suppose isn't too bad.

It makes more sense to me that trust attestations are made against a release event and not just each individual binary. What if the author accidentally included a binary from the previous release? the hashed file would still have trust attestations attached.

How would you highlight that a previously issued release package shouldn't be trusted as it contains incorrect version? With a replaceable event the author could quietly update it and the user wouldn't know that they didn't use the correct binary.