.txt refresh should send User Agent header

[eapl-gemugami]

Currently the refreshing process is not sending any header to indicate the User-Agent.

I think it would be a good idea to do send it, perhaps following the original spec: twtxt 1.2.3 spec - Discoverability

There are a few others, although I think the original one is enough to notify "I'm reading and replying you from this .txt file and this is my (suggested) nickname"

It looks like this: twtxt/[TWTXT_VERSION] (+[URL]; @[NICK])

For example: twtxt/1.2.3 (+https://example.com/twtxt.txt; @example)

A few questions:

• Are we still using the 1.2.3 version?
• Should we use that original spec?

I'm currently working on a proof of concept based on these premises

[sorenpeter]

I believe the version number is of the client software, not the twtxt protocol.

This is what other clients provides:

yarnd/0.15.1@23540da 2024-10-26T06:47:49+10:00 go1.23.2 (+https://twtxt.net/user/prologic/twtxt.txt; @prologic)
yarns/main@4e00b49 (search.twtxt.net Support: https://search.twtxt.net/support)
jenny/latest (+https://www.uninformativ.de/twtxt.txt; @movq)

so for Timeline, I suggest something like this: timeline/main@ee7e655 (+https://example.com/twtxt.txt; @example)

[eapl-gemugami]

You are right, it should be the client version.

Context: I was confused as the reference client also contains the spec itself: https://pypi.org/project/twtxt/#history <- different python client versions https://twtxt.readthedocs.io/en/v1.3.1/user/twtxtfile.html <- the spec I usually check as a ref, being the latest as 1.3.2

main@ee7e655 is the latest commit from Git, right? I think it would be difficult to get it from the PHP code, although it could be read from a VERSION file in the repo or something.

And if I can suggest, I'm fan of using dated versions such as "2024.12.01" because they have more meaning that the commit has, and allows you to know if you have an 'outdated' version.

[sorenpeter]

I have not made any released of timeline yet, so we can still make up the version scheme as we please. I like the date format, reminds me of Ubuntu, so we can roll with that. Or just do /latest like jenny

[sorenpeter]

For this to work we need some internal way for timeline to know what version it on. Do you have any ideas how to make that?

[eapl-gemugami]

Sure! The simplest approach is having a version.txt file which is used to know in the version changed when the branch is pulled. Usually I refresh the date, like 2024.12.03 for today. Random example: https://github.com/Tencent/behaviac/blob/master/version.txt

Also a file with metadata could be used like Composer (and a few other dependency managers) do: https://getcomposer.org/doc/04-schema.md#version Timeline doesn't use a dependency manager, so I don't see it as an option yet.

Anyway, in the meantime it could be latest without issue. I think the exact version is not really relevant for now.