unwriter / b Goto Github PK

If I set pay.rpc: "https://bitcoinsv.si" datapay lib returns error NodeError.

I'm a node noob, how can I debug || what must I setup on my end so I can replace default rpc on https://bchsvexplorer.com ?

Having separate blob with tx list might cover large files?

The 'encoding' field for specifying the character encoding is being overloaded in the wild to support content-encoding since no field exists for this specific purpose.

Here is an example tx which uses gzip compression on an html:

The encoding field is being used to specify the content-encoding gzip. This information is required to decode and render the content. While many content types are specific enough to include the compression information, many common content types are not such as text/html.

This issue is avoided in practice by overloading 'encoding' to define both types since knowing the content-encoding (gzip) can help you assume a binary character encoding, but this may not be safe in all cases in the future. You can imagine scenarios where some data might be compressed but with a resulting character encoding other than binary / converted to some other character encoding afterwards for some reason. This would be impossible to express in B's current form.

In my case, I am writing a TXO parser that relies on the value in the 'encoding' field to dictate which pushdata should be used for this content (out.b(x) vs out.s(x)). If the value is 'gzip' or similar, the "correct" thing to do according to the spec would be to produce an error as this is not a valid character-encoding. I cannot make a reliable determination without assuming the character encoding.

According to the docs, one design goal of B was to be both:
Simple: Simple to implement
Extensible: Future extensibility with additional push data support

With this in mind, I propose adding an additional optional field for 'content-encoding'. This would be added after filename as to be backward compatible. If omitted, it should be assumed to have a value of 'identity', i.e. no additional compression or modification. If there is no compression, no changes are required for application developers writing B content to the chain. If there is compression, you must specify the content encoding as well as the character encoding.

The results would look like this:

OP_RETURN
  19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
  [Data]
  [Media Type]
  [Character Encoding]
  [Filename]
  [Content Encoding]

Another example:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [ArrayBuffer from the file] text/html binary index.html gzip

The only alternative I can think of other than defining a new protocol is:

• If the character encoding is not a valid type, assume it is binary and use the value instead to define content-encoding.

My problem with this is, it has a potential to break in the future and is not really "simple" since you would need to know this and its not immediately obvious.