is it me or is this going to result in massively long data files that you KEEP having to re-downloading in their entirety every time you want to get an update from someone you follow?
This could be solved by archiving/rotating old entries, and have the webserver return the n latest.
For instance, you could let nginx do this:
location /masukomi.txt {
default_type 'text/plain';
content_by_lua 'local tail = io.popen("tail -n 20 ".."/chroot/twtxt/masukomi.txt", "r")
for line in tail:lines() do
print(c, line)
end
';
}
The problem is that if you didn't fetch the file at the right time, you will lose some history after rotation happens. At the very least, it needs a standard way to deal with that (like a mandated date-based URL format?), which has to be specified in the format.
Also, no DM and no @-replies. For those, you need a registry of some sort, but decentralized registries enable name-squatting.
Before you know it, you have reinvented the WWW, except limited to 140 chars.
> if you didn't fetch the file at the right time, you will lose some history after rotation
Very true, and that's a trade-off, not unlike what Twitter does today. In my pseudo-code I didn't make the -n part of the url (it easily could be, but that'd add changes to the client). So I agree with your criticism, but a "since" lookup would be a fairly easy extension of the client (i.e. part of query, so unsupported frontends still work), as the data file already contains date.
This is nice as long as nobody changes old status updates. Thought about using If-Modified-Since to at least reduce the load when nothing has changed at all.
But still: It will definitely take some time till a "twtxt timeline" causes more traffic than browsing the current Twitter homepage. :3
For instance, you could let nginx do this: