Searching We.Love.Privacy.Club

Twts matching #Timeline.
Sort by: Newest, Oldest, Most Relevant
In-reply-to » New post (mostly follow-up on the previous with a few new points) on the twtxt v2 discussion. http://a.9srv.net/b/2024-10-08

@2024-10-08T19:36:38-07:00@a.9srv.net Thanks for the followup. I agrees with most of it - especially:

Please nobody suggest sticking the content type in more metadata. 🙄

Yes, URL can be considered ugly, but they work and are understandable by both humans and machines. And its trivial for any client to hide the URLs used as reference in replies/treading.

Webfinger can be an add-on to help lookup people, and it can be made independent of the nick by just serving the same json regardless of the nick as people do with static sites and a as I implemented it on darch.dk (wf endpoint). Try RANDOMSTRING@darch.dk on http://darch.dk/wf-lookup.php (wf lookup) or RANDOMSTRING@garrido.io on https://webfinger.net

⤋ Read More

It has twts cache which used if timeline is set to jew. Maybe i.should fork twet to make wishes like newlines (i see two squares), showing conversations, showing twts if not found in cache and parsing medata to configure url, nick and followers (currenly it duplicated in config and twtxt file)

⤋ Read More

Thank you @aelaraji@aelaraji.com, I’m glad you like it. I use PHP because it’s everywhere on cheap hosting and no need for the user to log into a terminal to setup it up. Timeline is not mean to be use locally. For that I think something like twtxt2html is a better fit. (and happy to see you using simple.css on you new log page;)

⤋ Read More

So this is a great thread. I have been thinking about this too.. and what if we are coming at it from the wrong direction? Identity being tied to a given URL has always been a pain point. If i get a new URL its almost as if i have a new identity because not only am I serving at a new location but all my previous communications are broken because the hashes are all wrong.

What if instead we used this idea of signatures to thread the URLs together into one identity? We keep the URL to Hash in place. Changing that now is basically a no go. But we can create a signature chain that can link identities together. So if i move to a new URL i update the chain hosted by my primary identity to include the new URL. If i have an archived feed that the old URL is now dead, we can point to where it is now hosted and use the current convention of hashing based on the first url:

The signature chain can also be used to rotate to new keys over time. Just sign in a new key or revoke an old one. The prior signatures remain valid within the scope of time the signatures were made and the keys were active.

The signature file can be hosted anywhere as long as it can be fetched by a reasonable protocol. So say we could use a webfinger that directs to the signature file? you have an identity like frank@beans.co that will discover a feed at some URL and a signature chain at another URL. Maybe even include the most recent signing key?

From there the client can auto discover old feeds to link them together into one complete timeline. And the signatures can validate that its all correct.

I like the idea of maybe putting the chain in the feed preamble and keeping the single self contained file.. but wonder if that would cause lots of clutter? The signature chain would be something like a log with what is changing (new key, revoke, add url) and a signature of the change + the previous signature.

# chain: ADDKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w 
# sig: BEGIN SALTPACK SIGNED MESSAGE. ... 
# chain: ADDURL https://txt.sour.is/user/xuu
# sig: BEGIN SALTPACK SIGNED MESSAGE. ...
# chain: REVKEY kex14zwrx68cfkg28kjdstvcw4pslazwtgyeueqlg6z7y3f85h29crjsgfmu0w
# sig: ...

⤋ Read More

ProcessOne: ejabberd Docs now using MkDocs
The ejabberd Docs website did just get a major rework: new content management system, reorganized navigation, improved markdown, and several improvements!

Brief documentation timeline

ejabberd started in November 2002 (see a timeline in the ejabberd turns 20 blog post). And the first documentation was published in January 2003, using LaTeX, see [Ejabberd Installation and Op … ⌘ Read more

⤋ Read More

The wording can be more subtle like “This feed have not seen much activity within the last year” and maybe adding a UI like I did in timeline showing time ago for all feeds

Image

I agree that it good to clean up the Mastodon re-feeds, but it should also be okay for anyone to spin up a twtxt.txt just for syndicating they stuff from blog or what ever.

The “not receiving replies” could partly be fixed by implementing a working webmentions for twtxt.txt

⤋ Read More
In-reply-to » I've gathers my ideas about mentions for twtxt/yarn here: Webmentions vs. custom mentions spec for twtxt/yarn - HedgeDoc You are welcome to edit and comment in the doc, so our ideas are not fragment into a bunch of treads

@bender@twtxt.net you can over at http://darch.dk/timeline/conv/ba3xbfa or by looking at the raw txt https://lyse.isobeef.org/twtxt.txt
I can’t help it that twtxt.net only have temporary caching ¯_(ツ)_/¯

⤋ Read More
In-reply-to » I've gathers my ideas about mentions for twtxt/yarn here: Webmentions vs. custom mentions spec for twtxt/yarn - HedgeDoc You are welcome to edit and comment in the doc, so our ideas are not fragment into a bunch of treads

Thanks for your feedback @lyse@lyse.isobeef.org. 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

⤋ Read More

@shreyan@twtxt.net What do you mean when you say federation protocol?

I’m not sure we need much else. I would not even bother with encryption since other platforms does that better, and for me twtxt/yarn/timeline is for making things public

⤋ Read More
In-reply-to » @eaplme Yarn could the twtxt I want more then regular twtxt. Though I do like not having to host a yarn pod.

@eaplme@eapl.me

Didn’t know of bytesypider and bytedance, I assume those are bots, although I no idea why they are pointing to that address to your site
https://wordpress.org/support/topic/psa-bytedance-and-bytespider-bots-recommend-blocking/
You gave me a good idea to block bytespider. Its just weird what it pulls in.

twtxt-php isn’t sending User-Agent headers as it’s in the original spec:
https://twtxt.readthedocs.io/en/latest/user/discoverability.html
sending user agent would be a nice thing to have so that people using regular twtxt clients can find you and anyone else hosting twtxt-php or timeline

HTTP logs are annoying but webmention has an issue that it needs a server to check for webmentions. The server can be an external one or hosted on the same server as far as I can find.
But also HTTP logs need a server that one can view the logs.

⤋ Read More
In-reply-to » I am thinking about setting up a yarn instance. Twtxt is cool but it would be nice to be able to post from my phone. Local posting would be a cool feature for yarn to have. A feed that can only be viewed by logged in users of that instance.

@eaplme@eapl.me
Yarn could the twtxt I want more then regular twtxt. Though I do like not having to host a yarn pod.

That client looks really cool. A web client that connects to a regular twtxt without the need to host a full yarn pod for just one user and feed.
What is the difference between twtxt-php and timeline from sorenpeter? Does it have a way to follow feeds from the web ui?

I was looking at it and what prevents someone from downloading the .config file and getting the password? Also how would I generate a totp password to use?
I should try to host that it might be the right not a full on yarn pod but also can post from my phone.

The weird thing is in my server logs it shows that your site pulled in the useragent as https://eapl.me/twtxt/?url=https%3A//neotxt.dk/user/darch/twtxt.txt with bytesypider from bytedance? That sounds weird. Plus I can’t grep just twtxt in my logs and find your feed.

⤋ Read More

@prologic@twtxt.net You will have to agree that always using reply (like I am doing on this one) loses everything on translation after the third or fourth replies. It simply doesn’t promote engagement. On top of that, all replies show on the timeline as well, without much—to none—context.

⤋ Read More

Improving Git protocol security on GitHub
We’re changing which keys are supported in SSH and removing unencrypted Git protocol. Only users connecting via SSH or git:// will be affected. If your Git remotes start with https://, nothing in this post will affect you. If you’re an SSH user, read on for the details and timeline. ⌘ Read more

⤋ Read More