

Recent posts from feeds followed by sorenpeter@darch.dk
Wow, it seem my #Webmentions implementation works from Mastodon via brid.gy
@eapl.mx Super to see you got webmentions working too :)
EDIT: A webmention was send to: https://eapl.mx/timeline/webmention (Status: 202)
Great to see another user @aelaraji - And I can confirm that my #webmentions works from your server (I know, the formatting is messed up;)
@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?
Ehm.. you are now asking above my paygrade 🤣 I really don't know. Haven't look into webmentions, let alone how it is implemented in Timeline. What happened?
Hey, @bender I know. Just wondering the kind of apps or software and how you all stay up to date in conversations. Is it through webmentions?
@sorenpeter 's webmentions uses this trick: http://darch.dk/mentions-twtxt
(#<2024-09-24T12:34:31Z https://twtxt.net/user/prologic/twtxt.txt>) WebMentions does would work if we agreed to implement it correctly. I never figured out how yarnd's WebMentions work, so I decide to make my own, which I'm the only one using...
I had a look at WebSub, witch looks way more complex than WebMentions, and seem to need a lot more overhead. We don't need near realtime. We just need a way to notify someone that someone they don't know about mentioned or replied to their post.
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.