Delegator/delegate content type mismatch

[arik-so]

When an inscription has a delegate, the content and preview endpoints are served with the delegate's mime type, as one would expect.

However, the delegating inscription's details page shows the mime type corresponding to the inscription itself which, while technically correct, doesn't tell the whole tale. It might be prudent to show the mime type of the inscription whose content is actually being returned, possibly alongside the inscription's own mime type.

[arik-so]

I believe the same situation might also apply to the encoding field.

[gmart7t2]

Is it safe to inscribe delegate inscriptions with no body, content type, or content encoding tags, and rely on those 3 things being picked up from the inscription that is pointed to by the delegate tag?

[gmart7t2]

I notice that the master branch currently requires a file to be specified when making a delegated inscription, and includes that body in the envelope. This seems like a bug maybe?

[arik-so]

@gmart7t2 it is perfectly safe to create inscriptions that contain neither body nor MIME type. They will work perfectly fine just containing the delegation instructions.

[gmart7t2]

@gmart7t2 it is perfectly safe to create inscriptions that contain neither body nor MIME type

I know it works for now. I am wondering if it will continue to work going forward

[arik-so]

I don't see a reason why not, especially considering the comments on #3027.

[gmart7t2]

I've noticed that omitting the content type causes magic eden not to be able to display html inscriptions

[arik-so]

Yes, that's why we now introduced an effective_content_type field in the API instead that they should be able to switch to to make it work seamlessly.