

Recent posts from feeds followed by pftnhr@blog.ratterobert.com
@eapl.me here are my replies (somewhat similar to Lyse's and James')
Metadata in twts: Key=value is too complicated for non-hackers and hard to write by hand. So if there is a need then we should just use #NSFS or the alt-text file in markdown image syntax 
if something is NSFW
IDs besides datetime. When you edit a twt then you should preserve the datetime if location-based addressing should have any advantages over content-based addressing. If you change the timestamp the its a new post. Just like any other blog cms.
Caching, Yes all good ideas, but that is more a task for the clients not the serving of the twtxt.txt files.
Discovery: User-agent for discovery can become better. I'm working on a wrapper script in PHP, so you don't need to go to Apaches log-files to see who fetches your feed. But for other Gemini and gopher you need to relay on something else. That could be using my webmentions for twtxt suggestion, or simply defining an email metadata field for letting a person know you follow their feed. Interesting read about why WebMetions might be a bad idea. Twtxt being much simple that a full featured IndieWeb sites, then a lot of the concerns does not apply here. But that's the issue with any open inbox. This is hard to solve without some form of (centralized or community) spam moderation.
Support more protocols besides http/s. Yes why not, if we can make clients that merge or diffident between the same feed server by multiples URLs
Languages: If the need is big then make a separate feed. I don't mind seeing stuff in other langues as it is low. You got translating tool if you need to know whats going on. And again when there is a need for easier switching between posting to several feeds, then it's about building clients with a UI that makes it easy. No something that should takes up space in the format/protocol.
Emojis: I'm not sure what this is about. Do you want to use emojis as avatar in CLI clients or it just about rendering emojis?
What are peoples #IRC setup? Do you have your own bouncer server or just have a you computer always on? And do you IRC on mobile?
@movq How hard would it be to implement something like (#<2024-10-25T17:15:50Z https://www.uninformativ.de/twtxt.txt>)
in jenny as a replacement for (<a href="?search=twthash" class="tag">#twthash</a>)
and have it not care about if is http(s) or a g-protocol?
Video of my latest #livecoding show using #punctual for #visuals https://www.youtube.com/watch?v=CsM39SpRik8
Some more arguments for a local-based treading model over a content-based one:
The format: `or
(@DATE)both makes sense: # as prefix is for a hashtag like we allredy got with the
(#twthash)` and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.
Having something like `will also make mentions via [webmetions for twtxt](https://darch.dk/mentions-twtxt) easier to implement, since there is no need for looking up the
#twthash`. This will also make it possible to make 3th part twt-mentions services.
Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
Have not tried any of them, but some of these seem to fit the bill:
I just "published" a #draft on my blog about "How I've implemented #webmentions for twtxt" (http://darch.dk/mentions-twtxt), so I wanted to know from you guys if you see yourself doing a similar thing with yarnd
@prologic or others with custom setups?
Thanks for your feedback @lyse. For some reason i missed it until now. For now I have implemented endpoint discovery for #webmentions as a metadata field in the twtxt.txt like this:
# webmention = http://darch.dk/timeline/webmention
Added support for #tag clouds and #search to timeline. Based on code from @dfaria.eu🙏
Live at: http://darch.dk/timeline/?profile=https://darch.dk/twtxt.txt
Did another write up on #webfinger and DIDs for twtxt/yarn that you can read and edit/comment in: User lookup for twtxt/yarn - Webfinger or Decentralized Identifiers (DIDs) - HedgeDoc
I'm also more in favor of #reposts being human readable and writable. A client might implement a bottom that posts something simple like: <a href="?search=repost" class="tag">#repost</a> Look at this cool stuff, because bla bla [alt](url)
This will then make it possible to also "repost" stuff from other platforms/protocols.
The reader part of a client, can then render a preview of the link, which we talked about would be a nice (optional) feature to have in yarnd.
What about using the blockquote format with >
?
Snippet from someone else's post by: @eapl.me
Would it not also make sense to have the repost be a reply to the original post using the (<a href="?search=twthash" class="tag">#twthash</a>)
, and maybe using a tag like #repost so it eaier to filter them out?
#event Upcomming Meetup in Copennhagen: algolab(the_art_of_live_coding) @ Støberiet / Computer Klub
#makeartnotwar #GLSL #shaders code at https://www.shadertoy.com/view/fs2fRm if you want to use it
One year ago to the date I made the lastest update for #phpub2twtxt to github and now 365 days later I have published #pixelblog as its successor - lets see where things are going for trip around the sun
More #pixelblog'ing - today wotking on fixing all the semi-hardcoded paths an moving them to config.php
#pixelblog is slowly coming together with support for posting images and simple theming
#event Tomorrow, Saturday October 2nd, I'm gonna be hosting a workshop at Processing Community Day CPH about Live Coding Visuals in Improviz. Only 5 spots left, so sign up now at: https://pcdcph.com
Woohoo, #phpub2twtxt - my php interface for publishing to my selfhosted twtxt.txt is now online at GitHub