[bug/feature request] content negotiation is inconsistent between JSON and HTML, consider fixing #2

Pitch

When getting a user profile, it is possible to get a representation in both HTML or JSON. In the browser this can be done by adding .json onto the end of the profile. Using curl this can be done with the Accept header, and setting the mime type to either html of json

Notes on conneg: https://www.w3.org/DesignIssues/Conneg

When dealing with data and profiles its generally a good idea to have each variant return the same data to the client. Otherwise, depending on which accept header is used, the interacting system my yield inconsistent results

Motivation

Motivation for this is that it helps create more distributed and more decentralized systems. When building a tool that interacts with kosmos profiles the client doesnt need to know that the data in the JSON is much richer, or even different, to the the data in the HTML

This facilitates allowing more easily your kosmos profile to be an identity in hetrogenous systems. For example, by visiting a profile you may find public key material or a other cryptographic endpoints, that could be used for single sign on. So, for example, a kosmos user could sign in to a server providing solid storage solid apps, or unhosted apps in general, without necessarily needing to change the kosmos backend

Additionally, content negotiation is very hard to implement. Schema.org after many years dropped support for it. Deploying content negotiation to many other systems like nextcloud, or even dropbox, would be quite hard. However, deploying an HTML page to the cloud is relatively easy. In this way a data eco system can be created that interacts with kosmos.social, and that kosmos.social interacts with, where there is a low barrier to entry, leading to a greater network effect

Similarly it's easier to do things such as payments via profiles, which can be out of band, so creating projects like opentabs etc.

Solution

It has traditionally been quite hard to represent data in an HTML page. Firstly RDFa was tried, then RDFa lite and many other solutions. These never took off.

What has taken off is the schema.org pattern of using structured data islands.

What would be needed is a script tage that pulls in the relevent json in the html

It would look like

<script type="application/json">
... JSON goes here
</script>

And you're done

Conclusion

Please consider this fix to data consistency across profile pages with different mime types

IMHO you'd attract more developers, more users, more apps, and importantly, more functionality into the eco system

### Pitch When getting a user profile, it is possible to get a representation in both HTML or JSON. In the browser this can be done by adding .json onto the end of the profile. Using curl this can be done with the `Accept` header, and setting the mime type to either html of json Notes on conneg: https://www.w3.org/DesignIssues/Conneg When dealing with data and profiles its generally a good idea to have each `variant` return the same data to the client. Otherwise, depending on which accept header is used, the interacting system my yield inconsistent results ### Motivation Motivation for this is that it helps create more distributed and more decentralized systems. When building a tool that interacts with kosmos profiles the client doesnt need to know that the data in the JSON is much richer, or even different, to the the data in the HTML This facilitates allowing more easily your kosmos profile to be an identity in hetrogenous systems. For example, by visiting a profile you may find public key material or a other cryptographic endpoints, that could be used for single sign on. So, for example, a kosmos user could sign in to a server providing solid storage solid apps, or unhosted apps in general, without necessarily needing to change the kosmos backend Additionally, content negotiation is very hard to implement. Schema.org after many years dropped support for it. Deploying content negotiation to many other systems like nextcloud, or even dropbox, would be quite hard. However, deploying an HTML page to the cloud is relatively easy. In this way a data eco system can be created that interacts with kosmos.social, and that kosmos.social interacts with, where there is a low barrier to entry, leading to a greater network effect Similarly it's easier to do things such as payments via profiles, which can be out of band, so creating projects like opentabs etc. ### Solution It has traditionally been quite hard to represent data in an HTML page. Firstly RDFa was tried, then RDFa lite and many other solutions. These never took off. What has taken off is the schema.org pattern of using structured data islands. What would be needed is a script tage that pulls in the relevent json in the html It would look like ``` <script type="application/json"> ... JSON goes here </script> ``` And you're done ### Conclusion Please consider this fix to data consistency across profile pages with different mime types IMHO you'd attract more developers, more users, more apps, and importantly, more functionality into the eco system

Thanks for opening this issue. Unfortunately, it is not something we think should be changed only on kosmos.social. Please open an issue, or ideally a pull request, on the upstream Mastodon repo:

https://github.com/tootsuite/mastodon/

Thanks.

I just want to flag that this is actually a bug according to HTTP both the html and the json representation of a resource should contain the same data

I've raised an issue upstream for this, on the topic of building client to server apps, but it's considered too hard a problem, right now

Issue is that it might take a long time, even years to happen, and then more time elapsed for it to get downstream into kosmos

And it may never get fixed at all meaning that I would find it impractical to work on this system to build next gen dweb/social web/fediverse apps with new features ie such client to server, server to server, client to client (P2P), and single sign on

So during that waiting period it would be nice if there was something out there that can tie all these aspects together. The search goes on ...

I'll keep tabs on this issue and reopen if it gets fixed upstream