Feedback on TimestampIt! carried over from RFC3161.txt

gistfile1.txt

This gist is carrying over a discussion from a different gist: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710?permalink_comment_id=5147220#gistcomment-5147220

This gist was started so as not to disrupt the original purpose of that gist which is compiling a list of working RFC3161 TSA servers (with thanks to @Manouchehri for compiling and maintaining that gist).

@JohnPlanetary gave some nice feedback in this comment: https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710?permalink_comment_id=5151554#gistcomment-5151554

I am replicating the comment here:

> timestampit without RFC 3161 and RFC 5816 support doesn't make a lot of sense here in these topic. In fact I would argue that since RFC 3161 and RFC 5816 are the standards and are supported by so many programs that is still relevant, the magic part should be the part to be able to verify in the future that the file was really timestamped 23 years ago... I've been testing TSA's for a long time and basically is almost impossible once the TSA expires to proof anything since it will start to give errors... since CRL and or OCSP usually stop working and stops being possible to verify anything.
> 
> timestampit could have say a different key for every year using RSA 8192 bit SHA512 key to timestamp using RFC 3161 and RFC 5816, and say 150 years of year key lifetime, the main Root with say 500 years lifetime, RSA 16384 bit SHA512. and every year a new key with 150 years of key lifetime.
> 
> > TimeStampit Root Key (RSA 16384 bit SHA512) [From: 2024-08-12 - Until: 2524-08-12]
> > > TimeStampit 2024 Key (RSA 8192 bit SHA512) [From: 2024-08-13 -> Until: 2174-12-31] [signs between 2024-08-13 00:00:00 until 2024-12-31 23:59:59]
> > > TimeStampit 2025 Key (RSA 8192 bit SHA512) [From: 2025-01-01 -> Until: 2175-12-31] [signs between 2025-01-01 00:00:00 until 2025-12-31 23:59:59]
> > > TimeStampit 2026 Key (RSA 8192 bit SHA512) [From: 2026-01-01 -> Until: 2176-12-31] [signs between 2026-01-01 00:00:00 until 2026-12-31 23:59:59]
> > > TimeStampit 2026 Key (RSA 8192 bit SHA512) [From: 2026-01-01 -> Until: 2176-12-31] [signs between 2026-01-01 00:00:00 until 2026-12-31 23:59:59]
> 
> If the CRL('s) can be included within the signature (still doesn't happen in most programs) then theoretically the timestamp could be believed until its expiration date... as long the company itself doesn't have any troubles coming up like the private key being stolen or cracked.
> 
> RSA 16834 bit key with SHA512 should be fine for the Root, but usually can't be used for the final signing key because it will give too many errors at least in my tests it would fail on most signing programs because would take too many memory/ space reserved for the signature.
> 
> NIST P-521 could theoretically be used but the problem is that in reality the security level of it should be lower than even RSA 3072 bit key at least if quantum computing is used to try to find the private key.
> 
> Ok... but what if TimeStampit doesn't want to support RFC 3161 and RFC 5816? In what it would be different from other services online like: https://truetimestamp.org , https://opentimestamps.org , https://tzstamp.io , https://timestamp.decred.org and https://notbot.me ? What happens if TimeStampit closes in 6 years time, how would people be able to prove to others that timestamp is real? Some of the services above include some sort of bitcoin or other coin integration to make it more easy to proof in the future (as long those continue to exist)... in some cases judges may not accept them since it wouldn't be easy to verify by themselves and they may or may not believe experts, if it seems magic mumbojumbo... and to my knowledge there is no standard log database for timestamp similar to Certificate Transparency (where people can search for the certificate from multiple sources using for example: https://crt.sh ) where I think the certificate companies need to publish to more than one log database (at least one being from others not related to that company) in order for others to trust it and be able to verify things after the fact.

Hey @JohnPlanetary, thank your for your response and feedback, this is useful.

Regarding concerns about being able to verify TimestampIt! Trusted Timestamps far into the future, I have considered that TimestampIt! likely will not exist forever. All verification keys are replicated to a GitHub repository: https://github.com/timestampit/keychain. You can see this is a tightly controlled repo with signed verifiable commits and and a script for verifying the commits.

I am planning to add more places of replication as well including a GitLab repo and perhaps some other public file storage options. The example clients will be coded to make use of these backup key locations in addition to the official key urls from TimestampIt!.

There is also a "keychain" structure. When a new signing key is created, the previous signing key signs the new key (the activation_tt) and the new signing key signs the previous signing key (the 'retirement_tt`). In this way there is something like a chain of trust for keys.

When a new signing key is created, the previous signing key is completely deleted, reducing the possibility of leakage. As you can see, there is no "Root key" here, and there are no certificates with expiration times. Instead there is a "genesis" key and all other signing keys are signed in a chain of trust. Arguably my design is simply replicating part of what certificates are good for, but it is also a bit different and I feel more transparent and simple than using a full PKI infrastructure.

In my current thinking signing keys will be replaced when either one year has passed since activation, or after a certain threshold of signatures has happened (several hundred million).

I also want to note my intention was not to replace RFC3161 timestamps or take over places where RFC3161 was being used successfully. I want to open up new kinds of usage for Trusted Timestamps with a more accessible and extensible design. For example I am releasing a GitHub Action soon that will timestamp git repos. I believe my design is better than RFC3161 since they are plain text and readable and the ext field allows for user defined metadata (like git repo + sha information).

It is early days and experimental and your feedback is really appreciated! I'd love to keep the conversation going here with you or anyone else with feedback.

Also:

Ok... but what if TimeStampit doesn't want to support RFC 3161 and RFC 5816? In what it would be different from other services online like: https://truetimestamp.org , https://opentimestamps.org , https://tzstamp.io , https://timestamp.decred.org and https://notbot.me ?

I had not yet seen some of these sites, thank you for posting I will check them out.

I'm not a coder. Just a user.

I use timestamp for both my personal documents/ images and occasionally for evidence of things of third parties (ex.: someone says something will happen in the future).

While you probably should just focus on what governments; big/ medium/ small companies; and attorneys want, since probably most money is there I will still write a few ideas and considerations should the rare individual user like me for some unknown reason also matter to your business plan (maybe independent music and artists in general are the only type of individual people that may be interesting for your businesses model).

To be truly different of all other already available it should be possible to both verify the data online and offline... so that in say in year 4500 someone could go back in the logs and verify the data.

The only way I think that these can go "universal" is to be some sort of open protocol that others can also follow specifications and plug into/ be part of. Ideally from the start it should be possible for third party send their logs into the database that would obviously show the database own date & hour and the reported date & hour by that third party, so that both information is preserved and helps detect inconsistency on the information... obviously at the very least a few seconds are expected in third party logs since communication time and delays in processing information may happen, beside probably wrong time sync, but if it is being reported something with more that a few minutes of difference at least one can check that in third party and that may be significant or not depending on the situation.

The offline data should be some sort of "infinite" printing the information into high quality paper so that in 2000 years people can go search the logs in the physical papers that should be available all over the world in safe places and in few public libraries for example (if the protocol becomes widely used).
Not sure paper is the best medium to save the information since water and fire for example can damage/ destroy it easily.
Of course some sort of authenticity stamp that prints your brand on the paper itself in relief so you can feel the seal itself. Some sort of date should be added to make it even harder to fake using the same method. Yes, it won't be impossible for third parties to fake it, but at least would be one extra measure. Other things like ink properties, paper properties can also be added to make future forgery harder (yes, not impossible).
These logs should be on at least three (3) different locations at least hundreds of km way from each other, way from coastline.
I'm guessing in the beginning without money these can't be made, but if successful I give already the idea.

There should be simple and easy to use applications to submit the files on all main Operating Systems (Android, iOS, Mac, Windows, Linux, Ubuntu, etc.) including older version (so that it reaches as much people, governments, companies and organizations as possible). It should also be easy to check both offline and online the timestamp information on the application (be it from just one source and/ or from multiple sources).

The applications should all, from the get go, be open to third parties to be able to use it, so if someone else individually, or some other company, or some organization, decides to also provide the same service the user can send just to them or also to them (so that there is more sources with evidence should third parties want to check the information). Should be possible to submit simultaneous to more that one place (be it send to two (2) or say twenty five (25) different places). Should be possible to just use some link (that can be open to anyone to use or include the login magic in itself) , or also use username & password, or also use some certificate to authenticate. Should be possible to per-authenticate into the service.
If applicable the application could show by service how many times the timestamp was used, and/ or how many timestamps can still be used, and/ or until when the service can be used , and/ or a combination of all information so that the person can know where he/ she stands with that service. Because some may provide the service totally for free, but other may want to charge by day/ month/ year/ multi-year, or by number of times that the person can request timestamps and they may allow it for ever or just for 1 year for example, or may allow for free but say just 1000 requests per day, or say just 2000 request per month... lots of options... and I'm not even referring to all possible combinations of things that some service may want to provide... for example someone can be allow for free between some hours of the day and for the other hours only people that pay, other services may request people to just submit every 15 seconds if they are sending a big quantity of requests.... the imagination is the limit.

Opening the protocol/ log database and specially the application to third parties I think is the most difficult part to decide if you are going to do it like that or not, because you may make it too easy to change for the final customer, but people may be worried of being locked in a proprietary solution that may go way in the near future, and in some countries they may even don't allow such solutions to begin with (to promote competition and/ or some independence).

In the hash I would suggest: Argon2id or BLAKE-512 (there are other Blake variants more recent but they all seem to be made to be faster but less secure than the original... for something like timestamp ideally security should be top priority). Why not both? To be extra difficult to fake even in the future, since both algorithms would need to be vulnerable in a way that can make the final result be the exact same to both of them... maybe something like that will be possible in the future, not saying is impossible, just making things harder.

One thing to have in mind is that if users can control data they may try to include illegal things, say: images not very family friendly into the logs so they can retrieve them at anytime in the future... I think some electronic coins have these trouble, not sure how wide spread it is, but that definitely has happen in the past and may be happening in the present.
Not sure what can be done to prevent that sort of wrong use. In theory courts and other authorities may demand those contents to be destroyed, if is some additional user comment where the hashing is not involved I guess is easy to remove, but if the hash data is itself manipulated to have images or other things encoded that can be problematic specially if there is some sort of chain that can't be broken otherwise everything can be deemed not trustworthy. Of course authorities can also ask for the removal of some part or all of the log just because it damages their "national security" (or some other random excuse) for whatever the reason... that also needs to be taken into account... how can third parties keep some accurate record that anyone can search in 120 years and be able to be sure it was the original authentic data? And also be sure that the removal/ manipulation of data couldn't have spread to that archive if that data was obtain before any manipulation.

From my individual user experience I should be able to just drop some configuration file and have that specific service setup and ready to go, and of course allow to setup individually manually and allow to change settings if any is available/ applicable. If I want to use more services (say: send the same file hashing to other 10 different services) I should just be able to add them, and of course be allowed to select/ deselect on every individual occasional or just when I really want by going to settings. There should be the easy and the advanced mode... more options if I'm advanced user, less options if I'm the typical stupid person that needs the thing to work by itself has possible and I can't change anything that can screw everything.

When sending I should be able to just drop into the application, or get the file(s) from the application, or when the operating system allows that option, it should be possible to send file(s) into the application directly from the folder (at least in Microsoft Windows).

It should report if it was successful and if any errors where (say: some timestamp server may be down temporarily or even permanently)... and should allow for the file to be submitted to that service later in time either automatically or manually depending on the error returned.

It should also be easy to verify the file(s) by dropping into the verification part of the application. If some offline certificate was present it would be used for offline verification, and if the user wants it would also verify online those same offline verifiable sources. If no offline certificate were present the application could check the most popular log databases, plus or just any configured locally by the user.
The application should also be able to generate whatever information needed to submit in some online page to send/ receive that information (that can just report that one service, multiple services, or even all services). Specially useful if for some reason the application can't access the Internet or the user doesn't want the application to have internet access, or wants to generate the necessary information and submit using some third party service/ web site.

Thanks for your thoughts @JohnPlanetary

Many of these thoughts are inline with how TimestampIt! was designed. Some are not, I’ll try to respond concisely to those points. I’m not clear on the extent you have looked at the TimestampIt! design? Much of this feedback is pretty general, though still valuable.

To be truly different of all other [timestamps] already available it should be possible to both verify the data online and offline.

Truly offline verification is impossible as far as I know, short of having some trusted hardware with immutable root certificates/keys built in. I do not believe anyone has Trusted Timestamps that can have a 100% correct verification that is truly offline. However, you can get close enough to call it good I think. RFC3161 timestamps can verify offline using the TSA certs and your operating systems preloaded root certificates, and that is a nice design that requires industry wide coordination. BUT, a malicious program could potentially tamper with the preloaded certs, or could alter the verification program to use bad certs. I am sure there is other attack vectors.

The timestamps from TimestampIt! are verifiable without having an internet connection. All you need is a copy of the keychain (https://github.com/timestampit/keychain/blob/main/keychain.json). You can use our example verification scripts (https://github.com/timestampit/example_clients/) or write your own quite easily using any ED25519 signature verification library/app you want. The commits in the keychain repo are signed, and I am scheming some additional mechanisms for verifying the keys and ensuring they are authentic. Will it prevent a truly determined attacker, I suppose not. But using fresh keys on every verification gathered from a trusted source (like timezstampit itself, or the GitHub backup) largely mitigates this. Is it safe for 100s of years? I don’t know that anything in this space is. Quantum computers are coming and may render much of our cryptography broken.

The applications should all, from the get go, be open to third parties to be able to use it,…

TimestampIt! Is open to third parties to do what they want with it, though our terms of service permit only legal usage. But since the data works off hashes, we don’t really have any insight into what the source data actually is. If someone is timestamping illegal materials we are not going to know. And because TimestampIt! is just an API, you can use and standard program to create timestamps with it, like curl. The create/verify functionality on our website is really just for demonstration purposes.

The design of our Trusted Timestamps is also vendor agnostic. I would be honored if another TSA replicated or improved the design.

At some point, after getting more users and more experts to review the design and help improve the service, we might write an RFC and really standardize it. But for now it’s an experimental service and we are looking for expert reviewers to find the holes in the design.

I think your points about having a log database are interesting and somewhat inline with putting timestamps on a blockchain. Blockchain timestamps are pretty interesting but I have not seen a standardized design that does it well, especially when it comes to verification. It is something I have been thinking about. One challenge though: What kind of usage is important enough to justify the cost of using a mainstream blockchain to record the timestamps? AFAIK, no one really pays for Trusted Timestamps by themselves, though some users do pay for programs that make use of them.

Happy to take any more feedback that is specific to the design of TimestampIt! Trusted Timestamps 💚

As I told, I'm just a user, I'm not a coder.

These is important, because in order to test the service you would need to have a full working web site (signup is not working) and a full working application (at least for Microsoft Windows).

Well, offline verification is already a standard in PDF's: ETSI EN 319 142-1 PAdES B-LTA, and in EU the chain of trust can be obtain here: https://eidas.ec.europa.eu/efda/tl-browser/ So I guess we already have truly offline verification in place right now, as long as the application also keeps the timestamp CRL/ OCSP values also stored and that is something that I'm yet to see any program do... I can only get that by forcing it in Adobe, and even that won't work many times for unknown reasons to me.

If malware is present then nothing will be truly safe.

I understand the use of ED25519, but I would recommend against it, since even the most common available elliptic curve for use NIST P-521 is less secure then RSA 3072 bit... even if it doesn't come with some backdoor... at least when the technology allows for cracking current RSA and elliptic curves, the elliptic curves should be the firsts to be cracked successfully.

If you must use elliptic curves I would suggest a bigger one like "anders_1032_1" (1033 bit) available here: https://intern.fh-wedel.de/~an/crypto/accessories/domains_anders.html (that one is explicitly available for commercial use) still not the ideal, since is probably way small then what is really needed but at least when normal elliptic curves are cracked these one may still keep secure for a while (depending on the way they are able to revert from the public key to the private one) since is more then double the maximum size usually available and even then the more common use is those ED25519 and NIST P-256 elliptic curves that are way way smaller!
Of course you can do your own elliptic curve, and that is exactly what experts recommend, for every application/ protocol/ standard to have its own elliptic curves (if they use that) to make attacker life harder. The standards only benefit attackers both state sponsor and private ones. The experts only warning people doing their own curves to be careful to test them for some common mistakes that may render the elliptic curves insecure.

You did refer that you don't know anything that will be safe in 100's of years, and really the only way that could be possible would be to be in paper with all those things applied to make the forgery difficult and have that in some sort of permanent archive place that is keep by the public taxes. Other than that putting the information into the M-Disk's or similar long life physical medium, I don't see how that information wouldn't be lost. And who knows if in 300 years there will be any way to read M-Disk's even if there isn't some World Wide War.

The forgery of data, I think that there is already a solution that is used currently in the real world, basically as long who ever holds the data can be sure no one has change it, they can simply apply new signature algorithms on top of the old ones such that they can be sure that the information is valid in the future and hasn't been tampered. If they simply stamp a new newer timestamp with the current time at that time, or have some way to read the original timestamp time and transport it to the new timestamp information as a sort of "original timestamp preservation" I'm not sure... these makes sense, but I think they usually will only add a new timestamp to be sure no one changed the information and when they need to verify the data they will check the old original probably no longer secure timestamp... so the "transport" of the old data from the previous timestamp to the new one should/ must (!?) always have a field that informs the original document secure timestamp data, that way would be theoretically possible to keep the records securely updated & verifiable, even if old algorithms aren't secure since centuries ago (at that time).

"If someone is timestamping illegal materials we are not going to know.", I think you didn't understand what I told, they aren't sending hashes of illegal stuff that they hashed, they are using the "space" that the hash uses in the database to send their personalized encoded data such that they can store images in the databases even if they need to distribute over several "hashes" to then be able to retrieve that information from the databases, being the idea that as long that database is available and they have access to it, they can retrieve the information for example knowing the exact timestamps where that is stored to get the "hashes" and download them to revert into the images themselves. I know, why do that? So that they can always get the images back again later even if someone or something deletes them... they can find a way to neutralize whatever is doing that and then reconstruct the images from the database since that information can be made less obviously about what it is. At least is what I think can be the reason to store illegal stuff using the hash space in the databases.

"What kind of usage is important enough to justify the cost of using a mainstream blockchain to record the timestamps?" that is the point of the suggestion, not using some normal blockchain (that have transaction fees), but create one from the scratch just for these purpose that can be used by everyone and that can be replicated/ keeped locally by anyone who wants to check at anytime the information including offline... that is the kind of thing that courts usually like the most, something that can be easily obtain and checked for example by the judges themselves. Who would want to use such a thing? Notaries, Courts, Governments, and other legal industry that wants to keep timestamps in a permanent record.
But who wants that to be permanent? For example some government, company, organization, newspapers, that wants to know exactly when some document or transaction did take place, because depending in the laws or whatever they may be able to defend themselves or prove something in a way that everyone believes at least in the timestamp (since they can verify in the blockchain that it is really there).

"no one really pays for Trusted Timestamps by themselves", people do pay timestamps by themselves, there is no shortage of services selling that either individually or in a bigger "package". But mostly governments, private notaries, banks, lawyer companies, and probably many others that need to keep records and proof they didn't tampered them.
These is the reason I think the main focus of these would probably be those sorts of clients, if you want to charge for it and really make money.
Some solutions already announce integration with blockchain technology... but I'm yet to see one that is truly open and usable by anyone, and isn't just using some coin blockchain or some proprietary blockchain that one needs to pay to play.
Where would the money be at? The applications, hardware and maintenance contracts for those bigger clients. What about the "normal" people? Either you don't care about them at all in your solutions, or you can for example provide paid applications also for them for the timestamp, and for example free database online and offline viewer (and download of the database) for anyone to check the information. The application may allow access to anyone that supports the technology, and maybe allow a number of timestamps in a certain provider included in the application purchase.

"Happy to take any more feedback that is specific to the design of TimestampIt! Trusted Timestamps", to be fair I can't provide feedback on the specific design of TimestampIt! Trusted Timestamps, because of what I already wrote above "These is important, because in order to test the service you would need to have a full working web site (signup is not working) and a full working application (at least for Microsoft Windows).", and also because your service doesn't seem to have available anywhere some explanation that a person like me could understand, a good example of technology explanation is for example here: https://www.grc.com/sqrl/sqrl.htm where the "Secure Quick Reliable Login" technology is explain in a technical way I can mostly understand.

These is important, because in order to test the service you would need to have a full working web site (signup is not working) and a full working application (at least for Microsoft Windows).

I did have a bug that prevented signup from working, but it is now fixed. Signup and all other features on the website should now be working, including basic timestamp creation and verification (please let me know if you see otherwise 🙏). You can use public with password publicpublic to login and try it out too without signing up.

But it sounds like you understand the larger parts of the design pretty well already, and I do appreciate your expertise on the rest of the feedback, you definitely know more about this stuff than I do! I'll have to go through it more in depth.

As the design stands I am not using the hash algos you recommend, I do plan to support more hash algos soon though. My original thoughts on the design are I wanted to build a really nice modern API, and have other companies/entities build out the clients. So this initial launch I designed it to work with standard open source tools that are widely distributed.

I do take the point about people using hashes to do storage for actual files. The TimestampIt! servers only stores timestamps for 24 hours and then deletes them. Users are currently on their own for storing the trusted timestamps. I wouldn't want to store longer unless there is a paying customer which at this moment seems like a pretty remote possibility.

And I do intend to improve the documentation too and hopefully get something that makes sense to people who have never heard of trusted timestamps at all.

One thing I wonder about and perhaps you have some insight: Is there a good way to bring identity into Trusted Timestamps? Is there a good design that would record who created the trusted timestamps? I am thinking about people creating videos and wanting to mark them as authentic so that people could be assured they are not deep fakes. I could add email address into the data in the Trusted Timestamp, and only allowed recently confirmed email addresses to to create these identified trusted timestamps, but that feels pretty flimsy.

Thanks again for taking the time to engage with my admittedly novice project.

Yes, I created my account and now works properly.

I've tried, and it probably should also include a verification page to send the key, signature file and the file that was timestamp to check if all 3 are matching and are what they should and also present the information (time, hash, etc.) if everything is ok.

I've test sending just the file and it did work fine, it detected that the file was timestamped.

Since time stamping should be something that can be confirmed in a long time, and because you really want to just use standard algorithms, maybe then use SHA-512 or SHA3-512, and just not use SHA256 at all, and in elliptic curve use Ed448 (that is main stream since can be used in TLS 1.3 connections) and provides a litter better security level then Ed25519.

While I'm not an expert at the matter, I have a deep interest in these area because as I wrote before I like to timestamp stuff and definitely there is almost nothing that resisted the test of time until now, if I had to trust some online system to be available in the future I would probably go, currently, with https://truetimestamp.org since that has been around for years. Not saying that thing is perfect, just that has been working fine for years.

I would suggest to make your design to be picked up, to have working clients for the Operating Systems, to improve the chance people will really use it. They may be simple, but fully working, and you can encourage people to develop their own applications if they don't like and make it explicitly that your applications are aimed at proofing that everything works as advertised.

Yes, paying for infra-structure only make sense if you can get some clients to pay for it. But probably no one is going to pay if you don't have a clear good working system that makes sense and can start to be used immediately.

Usually timestamps are specifically and on purpose left without Identity associated to them so that it is as much usable everywhere as possible. RFC 3161 and RFC 5816 are a good example of that, they are used to sign PDF documents, but also executable, and anything else with external timestamps. Privacy is also a selling point to many since they can anonymously timestamp files. When people want to assign some identification they will either do that in the document/ image/ file himself, or sign with a digital certificate (usually using RSA or ECC algorithms).
Good example of program that can just timestamp, or just sign with a digital certificate, or do both, is: XolidoSign ( https://en.xolido.com/lang/xolidosign/xolidosigndesktop/ ). It uses the RFC 3161 and RFC 5816 for the time stamping, in that way is somehow limited since they don't include some online blockchain that can confirm the time stamps when they expire. But you can see that despite they provide that program for free for years, they have a lot of paid services for the companies, governments and who ever else wants them. So it is possible to provide free stuff for everyone and still make a lot of money.

This is good feedback @JohnPlanetary and thanks for trying out timestampit.com.

Since time stamping should be something that can be confirmed in a long time, and because you really want to just use standard algorithms, maybe then use SHA-512 or SHA3-512, and just not use SHA256 at all, and in elliptic curve use Ed448 (that is main stream since can be used in TLS 1.3 connections) and provides a litter better security level then Ed25519.

TimestampIt! does support SHA3-512 and a bunch of other hash algos, but only through the API. The reason the website form uses SHA-256 or SHA-512 is that is supported natively in all modern browsers. Once SHA3 gets supported I will definitely switch the web form to that.

I will also look into using ED448.

I would suggest to make your design to be picked up, to have working clients for the Operating Systems

I understand where this feedback is coming from. But I do not fully agree. Thick clients are just another point of trust that could be attacked. This is why my example clients are just thin open source scripts. And the design of my Trusted Timestamps are plain text and very easy to parse.

I have been thinking about some of your earlier feedback around making a global database of timestamps, whether it is a blockchain or something else. I think this is really interesting and is something I hope to work on at some point.

Some random thoughts on this:

Instead of a blockchain, a distributed hash table might be an even better data structure since it should allow for faster verification of timestamps.

Having some kind of token based market where users making timestamps pay a token to node operators who maintain the distributed hash table (or blockchain) could incentivize keeping the network operational.

What about simply putting timestamps into Twitter (X) as a place for permanence? Or Nostr?

For now I'll keep operating timestampit and seeking more feedback. I am going to publish my GitHub Action soon to allow timestamping code, hopefully that gets a few more eyes on this project.

If you ever want to talk more about timestamps or see other intersting developments in this space I'd love to hear about it!

Using social media for hash deposit has already been done, for example by originstamp, and if I record it correctly their account had troubles because Twitter identify the use of the account as abusive since they were probably using some bot to publish the information. I think they had to stop use Twitter for that (hash publishment), and any other social media will be subject to the same problem since any of them can decide at anytime they don't like that use and ban the person... of course one can have its own server with some social media application running but that would just be resource intensive, it would open a world of security troubles to take care... it would make more sense to just publish some log file of everything that could be searched on a webpage interface, and maybe even have for example some year/ month/ day folder structure where the main log would be cut to that specific day to make public indexing by third parties (like: https://archive.org/web/ and for example: https://archive.ph and common search engines) easier. And so html pages could be both PGP signed and the html file itself could be signed with for example some PKI digital certificate (.p7b format for example) using for example RSA 16384 bit SHA512 certificate for the owner and some timestamp. And include in the html file itself the OpenPGP key used and the PKI certificates used and the URL to find them on the web site (also available in html to allow easily index of it by third parties archievement web sites, to allow users and expert easier verification even if the service vanishes in the future).

"Having some kind of token based market where users making timestamps pay a token to node operators who maintain the distributed hash table (or blockchain) could incentivize keeping the network operational."

Yes, these is being done by some timestamp operations using bitcoin and other coin based systems, so it shouldn't be impossible. But if it is some distributed hash table or blockchain for just timestamp purpose (to make it faster) it will probably be harder to have a lot of people supporting the network, unless it becomes a standard in the industry and people can make real money with it. Specially the "distributed hash table" would be harder because with more and more people on the network the payment would go down and down to possibly near absolute nothing... at least I'm not seeing the possibility of charging even one cent of dollar to pay 10 000 database holders... each timestamp would cost 100 dollars, eh eh, not very realistic... I know no one that would accept such high prices. Lets not forget that not enough people will maintain a database network if they can't make money out of it somehow... of course those providing the services would be incentivise to do it, and maybe also some courts and similar, but not everyone so the success would be difficult (success in the sense of having a lot of databases around from multiple sources).