Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File data meta gzip protocols #5

Closed
wants to merge 3 commits into from
Closed

Conversation

shadders
Copy link
Contributor

Generic 'file' protocol based on Ryan X Charles' proposal.

Generic 'data' protocol

'meta' protocol for marking up other protocols with JSON meta data

'gzip' protocol for compressing data elements in any other data element based protocol.


### Filename

Contains any data element. However, it is recommended that the filaname be a utf8 character string. Furthermore, it is recommended that it be divided into name and extension like normal files: `<name>.<extension>` . Operating systems are already used to dealing with filenames and parsing meaning from them, so we can reuse code from operating systems for this.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"filaname" should be "filename"

@@ -4,6 +4,10 @@ Prefix,DisplayName,Authors,BitcoinAddress,SpecificationUrl,TxidRedirectUrl
0x00584350,Counterparty Cash,Counterparty Cash Association (CCA),17YhxKgKunLjvi7HB1ENGmeLwPFiaxb74V,https://counterparty.cash,
0x00746C6B,Keyport,Keyport,,https://keyport.io,
0x02446365,SatoshiDICE,Jon Bestman,1DiceuELb5GZktc3CMEv868DMtU3B5957x,https://satoshidice.com,
0x64617461,data,Steve Shadders,,,
0x66696c65,file,Ryan X Charles,,,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the credit :) minor issue, but for consistency it's best to have a period after the X - "Ryan X. Charles" :)

@libitx
Copy link

libitx commented Jan 28, 2019

Over the weekend I drafted my own simple file spec, unaware that I was duplicating @ryanxcharles own efforts. Having now read the specs in this branch, I've decided not to send my own PR, but will share my work here in case my approach offers any merit to the discussion of these specs:

https://gist.github.com/libitx/ad28a004be12e9f331f58821de60b039

My own comments/questions:

  • I believe the file and data specs cross over in a slightly ambiguous way. A file is essentially data with a filename, and I wonder if a single spec would serve better here? Perhaps using the data spec as the base, and where a filename is present combine it with the meta spec?
  • In ryans file spec, it becomes the consuming clients responsibility to work out the correct media type based on the file name and extension. I think it should be the tx authors responsibility to explicitly set the correct media type, not relying on file extensions.
  • In the data spec, it does become the tx authors responsibility to set a media type, but I think requiring longer form IETF RFC6838 media types would leave less room for error than the shorthand strings.

@ryanxcharles
Copy link
Contributor

the advantage of my approach is that the code to "work out" the meta data already exists:

https://www.npmjs.com/package/mime-types

filename and filedata are the standard way to transmit/record files on every system.

@tonesnotes
Copy link
Contributor

Filenames are valuable as long as they serve as identifiers, but they're weak identifiers. File extensions are likewise weak proxies for mime types. If the transaction ID (or a bitcoin address) are the real identifier, why not punt the filename and extension to metadata status and initialize the media type from the extension if possible?

@ryanxcharles
Copy link
Contributor

but filenames already exist and are ubiquitous. email attachments, download from google drive, dropbox, etc. the "file" proposal is simply about putting files on the blockchain as they are already standardized.

@tonesnotes
Copy link
Contributor

Okay. Makes sense. Maybe I'm thinking too much about reaching common ground. I do like the narrowly defined, composably collaborative approach of these specs.

@shadders
Copy link
Contributor Author

Closing this PR again in favour of updates discussed in telegram..

#8

@shadders shadders closed this Jan 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants