[bug/feature request] content negotiation is inconsistent between JSON and HTML, consider fixing #2
Labels
No Label
bug
dev environment
duplicate
enhancement
feature
idea
invalid
kredits-1
kredits-2
kredits-3
question
security
ui/ux
wontfix
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
release
major
release
minor
release
patch
security
ui/ux
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/mastodon#2
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 jsonNotes 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 resultsMotivation
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
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