Namespace proposal: app/*

Post Reply
shader
Posts: 2
Joined: Thu Aug 15, 2013 7:58 pm

Namespace proposal: app/*

Post by shader »

I'd like to propose a new namespace concept for application deployment, app/*

This namespace would be used by developers to provide details about an application, tentatively including the following possible fields (mostly optional):

name (full name, with spaces etc.)
author
version
hash or sig
url (homepage)
vcs (version control url)
docs
torrent (magnet uri)
btc
nmc
<altcoin> (these addresses can be used for donation, or for purchasing subscriptions/access codes in a decentralized fashion)
irc
license
bm (bitmessage channel or address for contact/news)

Those are a bunch of possible fields that I could think of, there are probably more. Please mention them here, or on the wiki. I'll add a page there for this namespace soon with more details about the fields. I didn't include all of the details here, because I'm not sure how to format them nicely.

As you can tell, there are fields that are variably useful for both open and closed source software. I think that this could be extremely useful for decentralized distribution and verification of software.

One of the salient points is the ability to link a verifiable short app name with a torrent magnet uri, because torrents are inherently immutable and therefor difficult to replace/update in a controlled fashion. Using a registration on this namespace, an app creator can easily and securely share updated torrent uris with their users. I think a similar concept could be useful for distributing named references to other content types, like v/, vid/, or video/ for videos; audo/ (m and a already taken), doc/ etc. though maybe they would be unified into one generic 'media' namespace.

It of course also allows you to easily find details on the past versions and their associated torrent files, contact info for the developers, donation details, website information, etc. Really anything you need to know about the app in summary.

Another use case that I'm hoping other people will appreciate is the ability to unambiguously specify in a computer-readable way which app is responsible for handling a certain kind of content, and where it can be found for installation. This would allow a program that has plugin support to recognize when it receives content with type 'app/fuzzywidget' and immediately tell the user 'this content is designed for use with the FuzzyWidget plugin <link>. Click here to install.' This step might require additional fields for package types, like rpm, deb, apk, etc.

With bitcoin/altcoin addresses included, the possibility of a global decentralized appstore becomes a possibility. Just send btc to the address, sign a message to one of the contact points with your btc key, and then the seller responds with activation instructions.

The possibilities are endless, enjoy.

moa
Posts: 255
Joined: Mon May 23, 2011 6:13 am

Re: Namespace proposal: app/*

Post by moa »

With bitcoin/altcoin addresses included, the possibility of a global decentralized appstore becomes a possibility. Just send btc to the address, sign a message to one of the contact points with your btc key, and then the seller responds with activation instructions.
What an awesome idea ....

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Namespace proposal: app/*

Post by virtual_master »

Good idea.
They are probably many possibilities of Namecoin uses what we didn't mentioned until now.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Namespace proposal: app/*

Post by domob »

I also think this could be a good application of namecoin, in particular as you point out to ensure verifiable downloads. I would however propose to change "btc" to "bitcoin", "nmc" to "namecoin", "bm" to "bitmessage" and add a "gpg" field to store signer GPG keys. This is to make it consistent with id/ names. (For instance, changing "bm" to "bitmessage" would allow anyone using Bitmessage with my recent patch to send messages directly to "add/name" without any change to the existing code.)

In my experience, the hardest part when verifying source downloads for software was always to find a trustable source of the signer key, even when .asc or .sig GPG signature files were provided together with the real archives. Thus this is a very important field, IMHO. (Of course, by storing the file's hash directly into namecoin you avoid having to sign in the first place. But it still could be useful to have the key stored there for reference.)

However, a bigger issue with your proposal is that it seems not so well suited to handle multiple releases of a package, or different types of releases (like .tar.gz, .tar.bz2 source tarballs, GNU/Linux i386 and GNU/Linux amd64 binaries, Windows binaries and so on). At least the version, hash and torrent fields seem to be specific to those releases. (Although in theory you could store all files of the project into a single torrent, but this seems complicated and would result in lots of people downloading everything although they just want the latest file, when they don't select only those files in their Bittorrent client.) How do you plan to handle those? Maybe just store project meta-data in the name (name, web site, vcs repository, signer key, donation address and stuff like that), which would still allow to get the signer key for a particular file and verify it? To handle machine-readable download of specific files / releases, one could provide a link to a page which describes the available files in some kind of JSON or XML format.

Also, are you aware of the current work on file verification (https://dot-bit.org/forum/viewtopic.php?f=2&t=1059)? This could also be integrated in some way, maybe.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

shader
Posts: 2
Joined: Thu Aug 15, 2013 7:58 pm

Re: Namespace proposal: app/*

Post by shader »

Yes, I'm aware of the existing work on file signing. I'm sure they can work together somehow. This brings me to a larger idea that I've been wondering about: is there a standard way to extend a namecoin entry by referencing another entry? If a user wanted to use all of the possible fields on either the d/ or app/ namespaces, the 1023 character limit wouldn't be enough. So has anyone come up with a standard way to extend/continue namecoin entries in a flexible manner? It could be very useful, if not necessary.

As for the ability to specify multiple distributions of the same software, it's definitely something I've been thinking about. This is after all just a rough draft of an idea. My first thought on how to handle it would be to use the top level value entries (url, torrent, sig, etc.) as the 'defaults' and then have a field labeled 'dist'. This would be an object whose keys were names of distribution types, like 'linux', 'win32', 'win64', 'ubuntu', 'deb', 'apt', etc. that each refer to objects that override the default values. So they could specify alternate urls, docs, signatures, torrents, vcs, etc. The actual required fields would depend on the package managers / platforms.

Unfortunately, including all of that information for a reasonably sized project will not fit into a single namecoin entry, so an extension method would be useful.

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: Namespace proposal: app/*

Post by domob »

shader wrote:Yes, I'm aware of the existing work on file signing. I'm sure they can work together somehow. This brings me to a larger idea that I've been wondering about: is there a standard way to extend a namecoin entry by referencing another entry? If a user wanted to use all of the possible fields on either the d/ or app/ namespaces, the 1023 character limit wouldn't be enough. So has anyone come up with a standard way to extend/continue namecoin entries in a flexible manner? It could be very useful, if not necessary.
I think there is, and the field is called "import". I've never used it myself so far, though, and can't tell you what / if any data consumers already support it.
shader wrote:Unfortunately, including all of that information for a reasonably sized project will not fit into a single namecoin entry, so an extension method would be useful.
That's why I suggested to not store that information at all in namecoin. I think it would be enough to have the "critical metadata", that needs to be authentic and secure, in namecoin, and keep all everything else external. You also don't propose to store the files themselves in namecoin (for obvious reasons), so why would it be necessary to store links to all available versions and platforms there? IMHO it should be fine to just store a single link to some sort of data structure, which describes the available files. This can still be machine-readable so that it would be possible to write package managers that can simply install "app/foobar" and automatically select the correct binaries (or build the sources if they like) and the latest version.

But I acknowledge this is already quite advanced. For a start, we could just stick with the meta-data. If there is consensus about what we want, the next steps could be to implement an online software directory that allows browsing and searching of all available app entries to make it useful ... do you plan something like that? Or even an alternative app manager for Android (for instance), similarly to https://f-droid.org/ (or even talk to them whether they are interested in working together with namecoin). Could be fun, and I would be sure to put my apps (only toy ones, though) there. ;)
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

Post Reply