32 ms·
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 /mas
by klapinat0r 11y ago
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
';
}
- toyg 11y agoThe 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.
- klapinat0r 11y ago> 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. > Before you know it, you have reinvented the WWW Yes. :)
- amelius 11y agoNo need for all this complication. Simply use IPFS[1] instead as the underlying protocol. [1] https://ipfs.io/ https://ipfs.io/