Nostr Web Client

You're heading in our direction, sir. 🤔

nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn y'all might need to just sit down and hash this out in a telephone conference. Y'all both went off to think and came back with something similar, but not identical.

Laeserin 1y ago

Since we're using Ngit as CLI, it makes sense to collaborate on it.

Laeserin 1y ago

I actually started off writing a Python CLI, but my interaction with you was so productive, that I was like,

Why do this twice? 😂

And, as you can see, we need to match at the CLI level, or the events will eventually lose interoperability.

DanConwayDev 1y ago

There is so much design space in #GitViaNostr, so few of us working on it and hardly any usage, that it makes less sense to duplicate functionality right now.

It is somewhat inevitable and eventually healthy when things are more mature as projects die, new projects do things better or on different stacks, etc.

Laeserin 1y ago

Yes, I think this realm isn't mature enough to handle competition on that level, yet. We're still working through the kinks in our own NIP-01, basically.

If we diverge too much, now, it's gonna be a shitshow and turn people off of the concept.

We should probably compete more on sw features, than on core event kinds.

DanConwayDev 1y ago

Yes, at a protocol level (event kinds and format), it is almost never a good idea to diverge.

Ľḭṿḙśƫṟãɖãṁṹṧ💫#RunCoreV30 1y ago

Product/ project manager experience taking

Laeserin 1y ago

Yeah, sorry. Used to managing complex sw projects and it occasionally leaks out.

Laeserin 1y ago

What is the value added by this collaboration? Can we find synergies and increases the reuse factor to maximize our ROI? 😜

Ľḭṿḙśƫṟãɖãṁṹṧ💫#RunCoreV30 1y ago

Perhaps not ideal outcome’s but Linux and FreeBSD development is an example

Ľḭṿḙśƫṟãɖãṁṹṧ💫#RunCoreV30 1y ago

It’s kind of obvious 🫡

Laeserin 1y ago

Ngit silos just sounds like a train wreck. 😂

DanConwayDev 1y ago

I think we are probably long overdue a dev call!

Laeserin 1y ago

Yeah, we are one step further on some of what you described and one step back on others. This is becoming inefficient.

DanConwayDev 1y ago

Welcome to the bizarre!

Laeserin 1y ago

😂

sommerfeld 1y ago

Where is your proposal? Is it just a proposal or there's a poc?

Laeserin 1y ago

We're not ngit maintainers, so we've been keeping our deliberations private, on Slack and in private repos.

We were considering forking ngit, but if Michael were a maintainer, we'd have less incentive to do that. Also, we just added a Rust developer, to the team, nostr:npub1w4jkwspqn9svwnlrw0nfg0u2yx4cj6yfmp53ya4xp7r24k7gly4qaq30zp

Perhaps we should deepen the collaboration to prevent drift. It's been mostly happening through my testing and should probably move to the ngit repo proper, otherwise it's just an effect of my person.

DanConwayDev 1y ago

Im open to the idea of more maintainers. Also, you don't have to be a maintainer to shape the vision and add features you want.

Laeserin 1y ago

Hmm. Yes. But it would take away motivation to duplicate the effort.

Laeserin 1y ago

And make me feel less like I'm cheating on him. 😂

DanConwayDev 1y ago

It would totally be worth while having a call to discuss our visions for #GitViaNostr.

I bet we would come up with new ideas and better approaches as our thoughts collide.

MichaelJ 1y ago

I think you and I have slightly differing visions, which is great, as we're less likely to clash.

I've been seeing ngit and GitWorkshop heading in the direction of the distributed/patch model of project organization. Setting up a multitude of git servers to act as relays for git objects that anyone can draw from is a good idea. That model is also excellent for open-source development, where contributions are driven primarily by fork submissions.

I'm personally leaning towards fleshing out the "cathedral" model. Tight-knit or closed-source teams might prefer that, with a shared git server and contributions coming from branches rather than forks. Even there, however, I aim for our solution to avoid centralization by using the basic model of repo discovery over Nostr.

In that sense, we definitely want to seek compatibility in the core model. Someone using GitRepublic should be able to submit patch proposals to an ngit/GitWorkshop user on the distributed model, and someone using ngit should be able to at least fork and create PRs against projects using GitRepublic and the cathedral model.

My hope is that we can maintain core interoperability but avoid unnecessary competition if we are aiming to serve different sectors of the market.

DanConwayDev 1y ago

Yes thanks for sharing.

Laeserin 1y ago

Currently, we have a gigantic external dependence in Ngit. Which is fine, so long as everything is fine.

But we have a strong incentive to duplicate or fork it, so that we can be maintainers. Otherwise, we get no credit for any improvements and if we need a bugfix and isn't available, we'll be forced to fork it and have our customers switch to our version in a rush. I've had that happen in a software project before and it's incredibly embarrassing to admit that you have no control over a core feature.

This is why everyone prefers to fork, rather than contribute. Contributing regularly to something you don't have your name on is cucky.

Ľḭṿḙśƫṟãɖãṁṹṧ💫#RunCoreV30 1y ago

Why not with selfhosted nodes?

Don’t hold binaries and dependencies but just code and version control with comments

🇵🇸 whoever loves Digit 1y ago

Don't forget to mention that you'll be happy to contribute later when your team is huge and it's just an intern taking a few minutes to submit your code to other projects via your own ngit platform

This is obvious to me but maybe not to people that have no idea who you are

MichaelJ 1y ago

Forking/collaborating is one option, but I'm also interested in parallel development on different tech stacks. If ngit is in Rust, then we can develop GitRepublic in C++, for instance. As long as we're working on lower-level tools, having multiple options in different languages out in the wild expands the space for others to build on that foundation.

DanConwayDev 1y ago

well said

sommerfeld 1y ago

I'm personally interested if we can replace git servers by blossom servers. Each blob is identified by its sha1 in git but each file is identified by sha256 in blossom so that might be challenging.

DanConwayDev 1y ago

nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume has been working on a blossom-based remote helper.

right now the repository needs to be entirely sha256 based rather than sha1. https://github.com/lez/git-remote-nostr

DanConwayDev 1y ago

I've been thinking about a parallel to blossom with git servers.

refs are stored in an event per https://github.com/nostr-protocol/nips/pulls/1249.

the data related to each branch tip can be fetched from `git:///`

the blossom git servers will accept any pushes match the tip of ref listed in a state event published by whitelisted npubs. They could even maintain branches `///`

MichaelJ 1y ago

Why replace git servers? Git servers are tried-and-true to the point that trying to re-implement them on a new tech stack would almost certainly be a step back. Any computer that has git installed can act as a simple git server; we should capitalize on that.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

just need a protocol adapter in my opinion, no need to change the git shell

nothing about nostr is especially prohibitive when used with ephemeral event kinds to carry protocol messages

the most tricky part is there is currently only REQ and COUNT so you would need to add a PROTO envelope or something, and also, you can make them more secure because you can require a time window tied to the push/pull inside the content field

sommerfeld 1y ago

Any computer can also act as a blossom server. After reevaluating, I realized what we need is not git server alternatives, but allow more stuff to act as a git server by making git itself understand and support new transport protocols (nostr:// or blossom://)

MichaelJ 1y ago

Yeah we really just need git object discovery via Nostr/Blossom. That's fairly simple, since all git objects are uniquely identified by a hash. So, on some level, all we need is a table of git object IDs and where to find them.

sommerfeld 1y ago

That was what I was trying to express initially: using blossom servers to fetch blobs by their hash. Issue is the incompatible hash...

gsovereignty 1y ago

I went down this whole rabbit hole when I rage coded snub. https://github.com/nostrocket/snub

Guga Figueiredo 1y ago

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

DanConwayDev 1y ago

I have been reluctant to replace core aspects of the git protocol as it is so battle tested.

Having a single git server that everyone pulls from isn't part of the protocol.

Its a point of centralisation and failure.

You have to trust that the operator is passing you the correct refs (as these are not signed although he commits maybe). Whats stopping them from pushing different commits to specific users or user from a specific country?

There is friction if you want change operator (as you need to coordinate with all the repo users to ge them to pull from a new url)

Laeserin 1y ago

We also are trying to circumvent gitservers. That's an unnecessary centralizing factor that wasn't part of the original git vision.

We have a solution for getting around them.

DanConwayDev 1y ago

I'm keen to understand it.

DanConwayDev 1y ago

Are you planning on hanging comments off an event that points to a remote branch for proposals/PRs?

Are you planning to track refs on nostr or leave that to the git server?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

it shouldn't be hard to integrate git shell with anything, including a relay

what i want to see, though, is ephemeral events that contain the pack message normally sent over SSH or via HTTP, so it needs a new nostr:// protocol handler

DanConwayDev 1y ago

I'm not sure you what benefits you can from sending the pack over nostr. It could be quite large. If its signed by the relay then you are trusting the relay rather than the maintainers.

Guga Figueiredo 1y ago

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

DanConwayDev 1y ago

ftw!

fiatjaf 1y ago

Is that a change in perspective since the last time we talked about it? Doesn't feel like it, which is good.

DanConwayDev 1y ago

No. Its the same approach.

MichaelJ 1y ago

It looks like you are leaning towards wrapping/extending some core git commands. The proposal mentioned overriding the function of `git push -u` to create a proposal.

One avenue we've explored at the CLI level is to wrap and extend core git commands. To use ngit as an example, rather than using commands like `git commit`, a user would do it all via ngit, e.g. `ngit commit`.

Any features that extend or override core git functionality, such as `push` in your write-up, would do the Nostr-y bits on a higher level, but delegate the core git operation down to the underlying git API. Any commands that don't have any special meaning in a Nostr context would be blindly passed down to core git.

That is, in part, why we chose C++ as our development language. Git is largely written in C, and interfacing with C APIs from C++ is fairly natural, and would facilitate the plan of wrapping and extending core functionality.

DanConwayDev 1y ago

I thought briefly about using the 'wrap and extend' approach but utilising native git where-ever possible plugs into the wider git ecosystem. I settled on using a git remote helper with set of extra commands triggered with ngit was the right approach.

Guga Figueiredo 1y ago

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?

DanConwayDev 1y ago

Ill repond to your questions in turn

Q1: how would the user know if the server, or comms channel is compromised? The refs aren' signed by the maintainer.

Q2: how would the code owner know the server is compromised? They don't knownwhat refs are being supplied to each user.

Q3: the remote helper would verify that the state event was signed by a maintainer.

Guga Figueiredo 1y ago

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?

DanConwayDev 1y ago

They were a point of failure anyway as they have permission to push to the git server.

I think the maim benefits of a remote helper are to make it easier to switch git server and make accessing propoals possible with native hit commands.

Guga Figueiredo 1y ago

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.

DanConwayDev 1y ago

Did you check out my concept? That outlines a few things. Eg submitting proposals via.`git push -u`

Guga Figueiredo 1y ago

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.

DanConwayDev 1y ago

I'm not entirely sure how I feel about it either. I think there is a strong case for it.

Users can view open proposals using just the git tools they are used to using.

It is a nostr remote so expectations can be set as to what to expect.

Its quite easy to understand that branches starting origin/prs/* don't come from the maintainers and that pushing a branch will automatically create a proposal.

Its smoother than the github forking model and having to create PRs in the browser.

I'd be interested in hearing more opinions and trying it out in practice.

Guga Figueiredo 1y ago

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.

ChipTuner 1y ago

I had some ideas about integrating archives and binaries into blossom as a CI job. Curious what your thoughts on handling files is?

DanConwayDev 1y ago

Super cool. For binaries, I thought about aligning with the work that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has been doing with nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcsrhspy. One or more 'App Profile' events could reference the repo announcement and share WoT heuristics.

A binary 'release' event linked to one or more 'App Profile' event then is a list of nip94 events referring to the each file in the release.

Trust attestations could be made against the repository, app profile, release, or authors of these events. You could have services like nostr:nprofile1qqsw3znfr6vdnxrujezjrhlkqqjlvpcqx79ys7gcph9mkjjsy7zsgygwr32sk's binary watch signing trust attestations for releases that support reproducable builds.

It makes a lot of sense to me to use 'App Profile' and not only because it aligns were the zap.store. A repository may contain one or more 'app profiles'. Maybe its a mono repo or has different releases for say desktop and andriod.

I've thought for a long time that DVM would be great to do CI/CD instead or relying on git hooks.

I'm keen to hear your ideas. What thoughts are bubbling away?

franzap 1y ago

This is great, would love to see us collaborating here.

Here's a basic class diagram of what's being used in zap.store in production:

Applications ("App profiles") are the proposed NIP-82 (kind 32267), see here: https://github.com/nostr-protocol/nips/pull/1336

Releases are already in NIP-51 (kind 30063) and point to one or more NIP-94 (kind 1063) file metadata events.

DanConwayDev 1y ago

Nice. I'd love that too. I've comment on the nip PR you just directed me to but I'll include my comments here for anyone who is interested

Love to see this and look forward to adding releases to nip34 clients.

Instead of referencing a nip34 announcement event in `repository` tag it should be referenced with an `a` tag so it will be indexed by relays. clients should look for an a tag with `30617` kind if repository is omitted.

The release event:

1. should be moved into this nip from the example section of nip51.

2. should be immutable and not a replaceable event. then trust attestations could be placed on the event eg. validation that the checksums of a reproducible build match.

3. should include an optional `["commit-id",""]` tag

From a style point of view: I see most nips describe events using jsonc rather than a table of tags, which is easier to read. Is this now the standard?

lastly, the app event could support the maintainers tag like nip34 announcements This means clients could optionally interpret app events by the pubkeys listed with identical `d` tags as referring to the same app. `["maintainers", "", ...]`

ChipTuner 1y ago

Great additions. I personally would love to see some way to verify a package. Source commit hash is a also a great addition.

I think a list of artifact hashes is important for authentication of binaries, we can, so we should.

Also I kind of like the idea of legacy PGP as an option as well. I suppose pgp files could be added as artifacts to the event to support this.

franzap 1y ago

I don't think there's a way to verify a package other than trusting the builder/signer. That's what reproducible builds are for.

Artifact hashes: yes, NIP-94

PGP: we're adding it to kind 0s! Currently building a tool developers will use with the ability to attach their PGP keys or certs. See

nostr:nevent1qvzqqqqqqypzq7xwd748yfjrsu5yuerm56fcn9tntmyv04w95etn0e23xrczvvraqywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcqypewzwqc7gf5vg36j2k472vrydefykd9pjw0mgr8qmfk5c629448cazxqs8

ChipTuner 1y ago

Artifacts should be signed by the developer IMO and attached to a source hash if the project is open source. Upstream depend on being able to verify binaries, when source isn't available, or the build process is too complex or undocumented, such is the case for polyglot systems or container based deployments.

DanConwayDev 1y ago

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.

franzap 1y ago

Definitely agree that attestations can't be placed on mutable events.

> What if the author accidentally included a binary from the previous release? the hashed file would still have trust attestations attached.

Doesn't this go against your point? If the author accidentally points to a wrong binary in a mutable release set event, they can update it.

A user cares about finding an attestation for the actual thing they're installing.

DanConwayDev 1y ago

If it were mutable, the author would need to revoked and reissue which would notify the users who installed the incorrect version.

I'm coming around to mutable. You wouldn't want to have to revoke a release to fix a typo in the change log. Clients could also keep track of the version they installed from and notify the user if a new version comes in with worrying changes in it.

franzap 1y ago

Right, I'm thinking clients could detect an update in the mutable release set, and then trigger double-checking the references file metadatas? As you say maybe it's just a typo and user needn't be prompted about it

ChipTuner 1y ago

Agree on release signing keys, I was lumping that into the dev's key, because presumably the developer (or their infra) holds that key. AKA developer's keys.

I suppose my concern is that there is enough information attached with my binary when I download it that I can trace it's hash to the source code (if open source) or that they developer told me this is the latest version, and here is it's signature. And you must trust that developer. With closed source this trust would be required. Just like in PGP, I don't know that we need/want a trust-less system here, if that is your suggestion?

Sorry if I am missing the point.

DanConwayDev 1y ago

I was trying to make the case for trust attestations made against releases rather than binaries like what happens with gpg signatures today. I'm coming around to them just being made against pubkeys, app profiles and binaries.

Given that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has already been building with mutable releases, I don't think there is a strong enough argument here to warrant a change.

franzap 1y ago

Thanks for considering that too, nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr .

nostr:npub1qdjn8j4gwgmkj3k5un775nq6q3q7mguv5tvajstmkdsqdja2havq03fqm7 we can totally add a git commit to the 1063

And btw you can recreate a checksum file by querying kinds 1063 with a #e of the 30063 - basically one query

ChipTuner 1y ago

Yeah fair enough. This is what I did on my website: I always have source tarballs associated with commits along with binary tarballs. The tarball hashes are individually signed.

I'm thinking for a mode where we have sdks and libraries that are being pulling into other projects during build time, where everything runs automatically and we want a secure way to verify artifacts during the upstream CI pipeline.

franzap 1y ago

Awesome. I'll answer on github

DanConwayDev 1y ago

Thanks for your considered reply. I'm interested exploring how this should shake down in practice.

Scenario: a project has 3 maintainers and 10 regular contributors and one of the contributors has a big positive reputation.

how should they go about issuing releases? assume we had trust attestations we could make against people, apps, releases (nip51 list) and release binaries.

franzap 1y ago

Gotcha, I was thinking along the same lines and we discussed this in one of our design calls. I heard an argument against listing maintainers/contributors and that's leveraging natural abstractions: Fabricating a pencil involves a huge amount of people and they're not all listed in a single place, that's what the price system is for. You pay a certain amount for the pencil and the company internally distributes payments.

If a project requires this level of detail they probably should be using something like nostrocket. Thoughts on this nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p ?

And again, I don't think kind 30063 releases should be immutable (file metadata definitely should). In all honesty, who do you think will be issuing trust attestations to an event pointing to binaries in 7 different architectures/platforms/OSs? Who would be vouching for all of those binaries at the same time?

franzap 1y ago

And by the way: we already have a way of including attribution. When I first floated this idea a few months ago I believe it was Pablo's recommendation to use the combination of `p` and `zap` tags to achieve it. NIP-57 appendix G goes over this mechanism.

DanConwayDev 1y ago

Nice. This seems ideal for recognising snd rewarding contributors

DanConwayDev 1y ago

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.

DanConwayDev 1y ago

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.

franzap 1y ago

Should zap.store be listed as maintainer of a project? Probably not. We're solving that in a different way: curators. Curators leverage their reputation and create lists and other nostr primitives to recommend apps. I would choose to install an app signed by a random developer but curated by two of my friends

DanConwayDev 1y ago

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.

franzap 1y ago

Totally. I am not persuaded about zap.store issuing app profiles. Let's say I want to recommend Mutiny Wallet and you follow Mutiny and zap.store... which one are you going to install? What happens when you have multiple curators vouching for Mutiny? To me, the signer is always the dev and then we can overlay trust attestations, badges, external service providers attestations – a DVM market/reputation will emerge for these kind of things

DanConwayDev 1y ago

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.

franzap 1y ago

We're definitely interested in being a curator and in fact we already are one (plan is with time to allow other relays and curators). We'll see how everything plays out, for sure there will be tons of developers that will not sign their apps and curators will have to in their place. I don't really like F-Droid's model for non-reproducible builds, I'd rather pull the dev build with their own certificate and stamp a nostr signature on it. Step by step 😄

DanConwayDev 1y ago

For me it depends on the app. I don't love the centralisation and their sometimes obnoxious behaviour; but I prefer my chances of being rugged by f-driod's build process than any one of 6 app developers build process.

franzap 1y ago

sure, depends, for critical apps (ie money) I would only use apps sourced from devs (better if it has reproducible attestation)

DanConwayDev 1y ago

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.

franzap 1y ago

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

franzap 1y ago

That's where OS permissions and software like opensnitch etc can help too

DanConwayDev 1y ago

I personally use nix, which allows me to easily build from source in a lot of cases.

DanConwayDev 1y ago

But it doesn't matter if the builds are reproducable if the source code contains malicious code.

ChipTuner 1y ago

To complement your example, I have been enjoying obtainium. Code directly from the developer. If I could I would want an app store that I can manually enter developer's keys into or do an openssh style "do you want to save this key" on first download, then subsequent updates will validate signatures as they are released. If the developer changes their keys, it should be a manual process or lots of blinking read lights. I don't want to trust an app store, like the case for F-Droid. I understand why they do it, but I like the model of, hey get this package from it's owner.

DanConwayDev 1y ago

Its not obvious but this happens by default with APK installed on android. The app must be signed with the a key and the key must match the already installed version.

Choosing the correct app when you first install it is the key.

frphank 1y ago

Apps from Google Play are signed by Google though not by the devs (anymore) and it's missing the UI part where it asks on override. I think that's what he wants.

ChipTuner 1y ago

Yes, but I'm speaking for a world outside of smart phones

DanConwayDev 1y ago

For sure. That would be great.

franzap 1y ago

you just described zap.store 😄

And yeah TOFU is the way. Android does it and we'll be bringing that to other OSes

franzap 1y ago

Yes I fully agree, this can definitely become a problem. I think though we're stepping on premature optimization territory. We can always add/migrate to the maintainers tag later if it ever becomes necessary, right?

DanConwayDev 1y ago

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

franzap 1y ago

Sure, it's all about striking the cathedral/bazaar sweet spot. Can't something like FROST solve this or do we need to bake it in now? A few weeks ago nostr:npub18z6qteykzjp4czp6uypnnrz3qv2u8gpkdnazwy2ejhneayj9zpvqzvn6df posted videos showing nostr multisig

DanConwayDev 1y ago

As I understsnd it, in an n/m you can only remove n-1 participants which wouldnt meet our needs.

franzap 1y ago

https://github.com/zapstore/zapstore/issues/23

Reply to this note

Discussion