# Technical design ideas

## Using a hash to created the permanent link

- Today the implementation has issues when cache gets cleaned up *("that is my understand" - Antonio)*

- Idea: *("I might be out of my knowledge area here" - Antonio)*
To use Bitcask to save the hash and have the values: user's URI and twt's timestamp associated with the hash. So when someone visits the link with the hash the values are recovered and the user's feed is accessed and the twt with the timestamp is displayed on its unique page. For this to work on other Pods the hash code be a MD5 of the URI + timestamp, this why any pod can create the perm link.
Example: MD5 for `https://twtxt.net/user/antonio/twtxt.txt2020-08-07T07:00:40Z` is `c19c3c476df72cc0766c505437691af0` the permlink (by convention) would be `https://twtxt.net/twt/c19c3c476df72cc0766c505437691af0` and could be made from any Pod. This could be part of the community agreed spec and other clients could implement the same way. Basically it is a solution on the client, since the client know the URI and timestamp of a twt it can create the link any time. This won't work for people outside that uses only a plain text file.

## Ideas for threads and replies

> One idea i had here was when replying to a Twt to generate a short hash of the Twt you're replying to and stick that in the (re xxx) (_by convention_) part of a followup Twt. The UI/UX side could extract these and group said Twts together in a single-level "thread".
> [name=James Mills]

> I like the idea of short hash when replying. I was trying to think how to make it a convention that could work across Pods.
> This gave me two ideas:
> ***First idea:*** Add an option in the client that the user could choose to add a short hash to every twt. Imagine like a check box below the post field. That would change the twtxt file to be: timestamp + *space* + `hash: c0766c5` + *space* + msg. Now when a user hits reply that would be added to the `(re c0766c5)` in the text box and be part of the message.
> ***Second idea:*** This idea builds on the first one above and we wouldn't have the `(re c0766c5)` in the twt message but instead add another convention to the twt file that would look like this: timestamp + *space* + `hash: c19c3c4 reply: c0766c5` + *space* + msg. Or if the user replying to the message doesn't use the hash option on their posts it would look like: timestamp + *space* + `reply: c0766c5` + *space* + msg. Now if a different client that doesn't care about that convention reads this twt the `hash: c19c3c4 reply: c0766c5` will show up as part of the message which in fact isn't too bad.
> And if you look above the idea of *permlinks*, perhaps that idea is irrelevant if we use this short hash, the short hash could be the permlink like: `https://twtxt.net/twt/antonio/c19c3c4` (added /antonio to the URI to help with uniqueness and know which feed to look of course, since Bitcask wouldn't be necessary anymore)
> [name=Antonio Rodrigues]

## Auto Updates

Using [this library](https://github.com/inconshreveable/go-update) we can build self-updating Twt Pods.

We can also consider using [this service](https://equinox.io/) which provides:

- Hosted updates
- Update channels (stable, beta, nightly, ...)
- Dynamically computed binary diffs
- Automatic key generation and code
- Release tooling with proper code signing
- Update/download metrics