💾 Archived View for bbs.geminispace.org › u › sirwilburthefirst › 1389 captured on 2024-05-26 at 16:53:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
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.
2023-06-01 · 1 year ago
🍀 gritty · 2023-06-02 at 02:11:
I already asked about this last year and both authors seemed to agree it would be scope creep to include. GTL does output your subscriptions to a gmi file that you can put on a Cron job on your capsule. this is what I do on mine until some kind of mobile phone capable client is made.
🍀 gritty · 2023-06-02 at 02:20:
I thought I'd already talked about this on here and I was right, back on May 20. sorry for the repeat. just bubbling it back on up?
🕹️ skyjake [...] · 2023-06-02 at 06:05:
I think there should be an open tinylog aggregator like Antenna/CAPCOM where you submit your tinylog URL for automatic aggregation. While it could display some number of the latest entries from the feeds, its primary value would be in providing a global directory of author IDs and feed URLs that Tinylog clients could access.
I believe @bacardi55's aggregator is manually managed (?).
🚀 bacardi55 · 2023-06-02 at 08:16:
What do you mean by "gemini-native tinylog reader" ?
To answer some question:
- Yes the current aggregator is manually updated.
- There were another client but not updated for some time
- I'm planning later this year to write a v2 of the TUI app to make it a lot better
- I didn't think about an antenna like aggregator, but it could be done easily, just need to spend some time to build it and I don't see that happening before late summer
A browser that can render tinylogs is great, but it wouldn't solve the discoverability or aggregation issues… I'll think more about it.
🕹️ skyjake [...] · 2023-06-02 at 08:45:
gemini-native tinylog reader
I think the idea there would be that the Tinylog client is a Gemini serverside app that you could use any Gemini client with.
🍀 gritty · 2023-06-02 at 11:11:
yeah I agree. I'm imagining a Masto/Twitter like interface where you log in with your cert, subscribe to feeds, and see your own timeline. I imagine this would mean a database that ingests tinylogs and stitches them together based on user subscriptions.
👻 sirwilburthefirst [OP] · 2023-06-02 at 11:40:
Sorry for the vagueness, I just meant there needs to be a way to subscribe and read tinylogs inside of a Gemini browser. Whether it's a built-in feature of Gemini browsers (which would be the best way) or a Gemini server app, both would be a massive upgrade. Nothing against TUIs (I love them!) but that's a niche tool even within the Gemini space.
I don't think discoverability is much of a problem. You discover through links. That works. Just a way that when you find a log you link you can subscribe to it. Automated aggregation would be a step up, but that doesn't scale. It eventually becomes too much to keep up with (and you're not interested in everyone's log).
🚀 bacardi55 · 2023-06-02 at 15:10:
I'm against the idea of creating a centralized place for tinylogs where all users would connect to post. That's not needed because both station and here generate a tinylog output. so in my view its not needed, but feel free to code it :)
I see 2 things I could work on that may help tinylogs spread more:
- An antenna like capsule, either via submitting tinylogs or just regestering it once. So there is an "autonomous" aggregator
- A server side app (mono or multi users) where people can create their own feed via registering to TL. Not allowing tinylog creation but would provide a gemtext personal feed without the TUI or anything but a browser needed. Could be selfhosted or hosted for the community.
🕹️ skyjake [...] · 2023-06-02 at 15:44:
(I have been thinking about tinylogs recently, hence the following comments...)
sirwilburthefirst:
I don't think discoverability is much of a problem.
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?
bacardi55:
a centralized place for tinylogs where all users would connect to post
Yeah, that would be unnecessary. The decentralization is essential; just put a tinylog.gmi on your server, and the client(s) should take care of the rest.
antenna like capsule, either via submitting tinylogs or just regestering it once.
I see two options for this that could work in practice:
A) Users self-submit their tinylogs to a common "registry" of tinylog URLs.
B) Search engines crawl Geminispace and provide the list.
Option A is requires people to particate, Antenna-style. Option B depends on search engines being smart/thorough enough. I suppose ideally could have both options at the same time...?
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.
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.
Posting to one's own Tinylog should be a different concern altogether, and the solutions range from manually editing a .gmi file on your server to using automated services like Bubble to generate the Tinylog for you. Ideally you'd have a specialized Tinylog client that is smart enough to automatically look up the @-references and provide a nice UX.
🚀 ivanruvalcaba · 2023-06-02 at 19:13:
My two cents: wouldn't it be better to adopt/extend twtxt[¹] format specification for this purpose? The only difference I see is the limitation in the length of the text (less than or equal to 140 characters. See: Format specification[²]), since the client application could perform the graphical representation of the gemtext markup.
There is currently a client application[³] (CLI) that supports the gemini protocol.
Best regards
¹ https://twtxt.readthedocs.io/en/stable/index.html
² https://twtxt.readthedocs.io/en/stable/user/twtxtfile.html#format-specification
³ https://github.com/jdtron/twet
🚀 bacardi55 · 2023-06-02 at 21:06:
@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).
👻 sirwilburthefirst [OP] · 2023-06-12 at 12:46:
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 😀