-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
@invanruvalcaba :
My big issue with twtxt is the format. It is not gemtext based and very limited (only 140 charaters and limited to 1 line). If we look at existing tinylogs, 99% of them use many lines and gemtext format to strutcture their text (quote, subtitles, …). So while the twtxt concept is interesting, I think it will limit its usage compared to a gemtext multiline based format and that would limit intereted people.
@skyjake :
Agree with your comments. Discoverability is an issue and right now either people email me their feeds or create a pull requests in the known tinylogs codeberg repo. Not ideal. I like the self registration approach!
The serach engine thing is nice, but an entire different beast so it would be outside of the scope of a tinylog "app" (client or server side), but that would be indeed the best to automate adding new tinylogs to a central aggregator.
> This works pretty well until the number of subscribed tinylogs is large, at which point it'll be beneficial to do serverside aggregation of tinylogs so a client doesn't have fetch a hundred different Tinylog URLs on every refresh. I think this is what you meant by your second point about a personal feed.
Yes exactly. I "follow" 30+ tinylogs feeds now and it's still very fast to refresh all (thx gemini pages being super light), but I already thought of something more efficient with better caching and smarter retry mode as it wouldn't scale for 100s of feeds. And a capsule app instead of TUI app might help people use it more.
> All of the above is basically about how a given client is able to locate all the tinylogs it needs to. In practice, a client could then proceed to fetch all the tinylog URLs and present whatever UI it wants to the user. […] Ideally you'd have a specialized Tinylog client that is smart enough to automatically look up the @-references and provide a nice UX.
Exactly that. Clients should be responsible for displaying things. Could be a classic timeline like gtl or you could create a more "dashboard like" page. But shouldn't be part of the spec.
Overall, this discussion is inspiring me to think about tinylog improvement again which is great :). I'm not as productive as Skyjake as a dev, but I'll think about the "server side client" soon. For GTL, I was also thinking about a v2 of the TUI (with a better TUI library that would allow a nicer UI).
2023-06-02 · 1 year ago
> IMHO, discoverability is a big problem. Since Tinylogs are decentralized, how to know what tinylogs exist? What are their URLs? If I see a "@username" reference in a tinylog entry (without any links), how to find the referenced tinylog file?
Why are there no links? There should be links, that's the solution to discovery 😀
The fact that there isn't a gemini-native tinylog reader is kind of a big problem. To my knowledge, the only way to follow tinylogs at the moment is to use the one TUI app that the spec creator wrote, use the hosted list of known tinylogs, which does not include all tinylogs (anywhere close to it) (how could it?)... and that's it. It will probably take a browser (ahem) having native support for the format to see more adoption.
-- Response ended
-- Page fetched on Sun Jun 2 13:22:19 2024