💾 Archived View for rawtext.club › ~sloum › geminilist › 005409.gmi captured on 2024-03-21 at 16:41:49. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
easrng easrng at gmail.com
Sun Feb 21 20:21:02 GMT 2021
- - - - - - - - - - - - - - - - - - -
Many of us strongly believe in the one pageload generates one requestphilosophy, including me, but metadata is also nice to have. While youcould put metadata in other files, that would result in multiple requestsbeing made. Instead, I am proposing a new file format,text/gemini-metadata+json, to be used in data URIs in Gemtext. It would bejson (simply because it is popular and has wide support) with specifiedkeys. Possible things to include in the metadata could be a favicon (be itemoji or otherwise), a theme color or color scheme to be used by the clientas it wishes, etc.It would be used like this:
=
> data:text/gemini-metadata+json;charset=utf-8,{"favicon":"👩%E2%80%8D💻"}Page metadata```
A Gemini client implementing this would add a check for links starting withdata:text/gemini-metadata+json to it's rendering code and when itencounters one, decode it and take note of the metadata. Clients notimplenenting it will just see a link to the data, degrading (imo) quitegracefully. I can't decide if the link should be hidden or not in browserswith support though. If the link is hidden then the client should make sureto expose the metadata elsewhere in the interface.Please give all the feedback!
-- easrng(Did I tag this right?)
-- 🍵 <https://www.google.com/teapot>-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210221/e9da64b2/attachment.htm>