simonbaird / tiddlyhost Goto Github PK

Obviously. Also sorting.

The original is an svg file with transparency and there's also an ico file. The transparency means you can't use it on a white page. Should create some pngs of different sizes and check them in. Maybe also fix the svg so it is visible on a white page.

The self-signed SSL cert running on localhost can be annoying. It's useful to test cert handling when needed, but for generally hacking I'd like to turn it off.

If we do lose some database changes (touch wood) blobs in S3 will still be there, but rails active storage won't know their keys. If we could discover the site id for a blob (or maybe user id and site name?), we would have a chance of recovering it.

I think S3 files have metadata. Can I poke some fields into it? If so then how?

..if it's available.

The database shouldn't be exposed, but still it seems like a sensible idea.

..or to begin with, maybe email notification on exceptions

It doesn't matter now but it will once we have a large number of users and sites.

It's a bad UX when you first sign up. If should be possible to make Chrome use the correct field to associate with your saved password.

Should check it in Firefox and Safari also.

Followup from #12.

I was thinking EKS & RDS, but it seems too hard to get it all working. :/
Something simpler maybe.

Simon, if this is too much off topic, just close it right away. No need to explain.

The need for a central hub for e.g plugin distribution is greater than ever after TS shut down. Could TH somehow have a "front" where all wikis that are somehow marked as "plugins" and other categories, appear? I.e they appear as links to their respective wiki.

It would be ideal if any user could add meta data to the listed instances on that front site, e.g to categorize the wiki(link), and maybe give reviews etc. (I have further thoghts on this, if it is of interest).

See also User stories for a community plugin library #5399 for relevant aspects.

Very large sites cause problems for Tiddlyhost, but it tends to be self-limiting since users realize this too. Maybe an oversize warning is a useful idea.

At the moment, anyone can have any site name, but maybe it would be better if there were "spaces" owned by one user, where you could choose a site name without it clashing with existing sites. It wouldn't be a proper subdomain in dns terms, but the "domain labels with dots" idea that used to work fine for Tiddlyspot. (Currently Tiddlyhost deliberately disallows '.' chars in the site name.)

E.g. notes.simon.tiddlyhost.com, aboutme.simon.tiddyspot.com

Only the owner of the space would be allowed to create sites in that space.

It would be possible to rename your space (I guess), and move sites to and from a space.

Requires some bootstrap wrangling.

I can't ping tiddlyhost.com. Restarting the instance didn't fix it.

From https://www.dreamhoststatus.com/

February 17, 2021 3:07AM PST [Investigating] Our Cloud Engineers are investigating an issue resulting in connectivity issues on customer DreamCompute instances. We are closely monitoring the situation and will be posting periodic updates as further information becomes available.

Currently it's in Google Domains. It might be that getting the letsencrypt to work with google domains is easy, but it's better if there's just one way to do it.

Note there's no username for users currently, so some new user schema is needed to do this.

Current plan: description, searchable, tags

I cobbled it together quickly with some bootstrap imports. Inactive and active buttons don't work properly.

See 061cd56 .

Also should return a 403 as suggested in that commit.

Probably will give them an html layout. Use multipart with plain text for mutt users if it's not too hard.

Google and Github maybe?

Take out all the unused fields. Add useful links and explanations. Generally improve the UI/UX for Tiddlyhost users.

We're running docker compose in prod with no front end. Is that wise?

Most people seem to run nginx..

Could maybe serve public sites straight from cache without hitting rails.

Would need to redo how certs are configured.

Puma could stop doing ssl if nginx reverse proxies the rails container.

Also load balancing maybe.

Maybe..? I dunno.

Maybe it doesn't matter much, but we can fairly easily add some credentials to the prod host to allow pulling from a private repo.

Seems like a good idea to have some kind of backup strategy

For example make shell is handy in development, but there's no such think in prod, so i have to type sudo docker-compose exec prod bash and that is annoying to type.

If they were created on the fly we wouldn't need the .keep file in the repo and the top level dir would be tidier.

Currently there's a few things that are specific to tiddlyhost.com

Considerations:

• Deployments
• Secrets
• Hostnames
• Certificates & Let's Encrypt
• DNS
• Configuration, settings etc
• Documentation, i.e. how to do it

There's two ideas:

• Someone checks out the code and builds their own container image, and uses that for their own Tiddhost instance.
• Someone uses the pre-built container image with all of the instance specific configuration applied at run time to make it work.

The second idea is cooler.

(Will probably not get to this for a while.)

Maybe it could update the $:/UploadURL value automatically.

Note, it should warn about saving your site first, and reloading afterwards.

Other options to consider:

• disallow renaming sites
• explain to user how to manually change $:/UploadURL

Currently the delete button is only on the sites list page.

It would be good if I could build/rebuild the openstack instance (using ansible probably) rather than try to remember what I clicked on to create it.

Also it would help with #36 if I could create an adhoc non-prod instance of Tiddlyhost easily.

There's pros and cons. One likely con is the expense.

Basic "site down" alerts

Less basic "site experiencing stress/slow response times/critically low disk space/etc" alerts

Advanced: Useful charts, stats, etc

Currently it throws a routing error.

What does TW expect to get back from this?

The sooner the better. Not for any particular reason, just so we're keeping up.

Should cut down total size considerably, which might reduce S3 costs.

For public sites with a lot of traffic caching should be effective. Currently we fetch from s3 every time a site is served.

Redis, memcached, something else?

I thought there was something in the container to run migrations on startup, but I've noticed it doesn't work.

Should probably make a staging server for unstable builds and demos etc.