noosphere icon indicating copy to clipboard operation
noosphere copied to clipboard

`orb` does not properly handle `vnd...+` clauses in content-type header value

Open justinabrahms opened this issue 2 years ago • 2 comments

I created a profile file locally and synced, but I don't see my profile in the app. You previously mentioned that the content-type is being set as application/vnd.subconscious.profile+json in the subconscious app, which may be the underlying problem.

justinabrahms avatar Aug 09 '23 23:08 justinabrahms

This is a bug in how we currently match media types (aka mimes). Basically "vnd...+" clauses will throw us off and prevent us from detecting file extension/mime relationships correctly.

cdata avatar Aug 10 '23 17:08 cdata

Copying over from Discord for posterity:

I've been going pretty deep on media types in the last few days. One thing that has come up for me is that although there is theoretically a pattern for us to deterministically/losslessly round-trip between a domain-specific content type and a file extension, it's not going to generalize to the broader universe of media types. And, this presents a challenge when e.g., rendering Noosphere content as a file system view.

Consider as an example this (non-standard) accounting of media types and their "common" file extensions: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

We have basic cases e.g., application/xml -> .xml. Fair enough. Now let's be Apple and make a vendor tree version of it for some domain-specific XML: application/vnd.apple.installer+xml -> .mpkg

In other words, the file extension is practically a convention and not deterministically derivable from the mime.

So, we "solve" file extension inference by using a giant map of media types to their plausible file extensions (sourced from third party). And, for things that are domain-specific Subconscious / Noosphere, we have a secondary map that handles things we know about.

Now, the Subconscious profile is a plain text file containing serialized JSON. If I'm a user of orb I can create a such a file. After filling out its contents, I would save it to disk with the .json file extension. Now, when I go to save it to my sphere, orb infers the application/json media type. And, this is the problem: we cannot infer from a generic, low-information file extension like .json that the media type we actually should save the file with is application/vnd.subconscious+json.

There are only two possible changes that I can think of to enable the orb user to do the right thing:

  1. Give them a way to tweak the content-type header manually
  2. Use a specialized file extension for application/vnd.subconscious+json

Option 1 is arguably something we should be able to do eventually, but it's extra work and unintuitive as a baseline UX. Option 2 seems more coherent/orthodox to me: every webserver I know of infers the media type from a file extension by default, and if you only have a handful of characters to convey the appropriate media type, there has to be a direct mapping between a file extension and a media type.

So, my recommendation at this point is to do one of the following:

  1. Use Content-Type: application/json for the Subconscious _profile_ content ...or...
  2. Choose a specialized file extension for application/vnd.subconcious+json, and orb will use that when rendering _profile_ to the file system

In the end, a decision was made:

Given the conversation above, my sense is that we should update profile to use JSON-LD.

This change will be implemented in Subconscious, and so the "fix" should trickle down to orb users from there.

cdata avatar Aug 15 '23 20:08 cdata