I looked into this a few years ago[1]. The solution I came to involves putting the hash of the most recent Bitcoin block in your document, and then signing the hash of your document into the Bitcoin blockchain.
This cryptographically proves that the document was created/published within those two time bounds.
This of course doesn't help in all cases, i.e. you could edit an old document to make it look newer, but I'm not aware of any way to properly solve that particular problem without a trusted third-party.
My main reason for disliking Snap is the fact that it allows anybody in the world to publish a package with minimal moderation. This completely undermines the inherent trust that system package managers should have.
When installing critical system packages, I want to be absolutely certain that these are legitimate/official, and that even if I make a minor error in typing a command, I won't inadvertently install some sort of typosquatted fake version of the package.
When using Apt with the default repositories, this isn't a problem at all, as only known, trusted packages are available. In other words, there's no chance of someone publishing a fierfox or apahce2 package to try to typosquat someone.
I don't even want to talk about the forced automatic updates either... these make it essentially impossible to have a stable/reliable system for specialist use cases, e.g. browser testing, bastion host, build environment, where control over updates is very important.
On the sandboxing - it's good in principle, but rarely seems to be implemented in a truly meaningful way, as ultimately once you have home drive access, you don't even need to worry about escalating privileges as everything valuable is probably in your home area! There's an xkcd about this somewhere...
Allow developers/engineers to use an OS and tooling that they're comfortable with. There must be choice between text editors, IDEs, browsers, shells, etc.
Also don't try to control this centrally. Once developers have proven themselves to be competent at operating a computer, they shouldn't be forced to use a locked-down corporate machine.
You can transfer a domain with no downtime. The name servers will remain during the transfer, so as long as your DNS isn't dependent on the domain registrar, you'll be fine.
If you are using the registrar's built-in DNS hosting, move away from this first, which can also be done with no downtime.
This cryptographically proves that the document was created/published within those two time bounds.
This of course doesn't help in all cases, i.e. you could edit an old document to make it look newer, but I'm not aware of any way to properly solve that particular problem without a trusted third-party.
[1] https://www.jamieweb.net/blog/proof-of-timestamp/