[l0b0]

Great idea! Some feedback:

- The 24 hour horizon means you could get away without namespace functionality like categories entirely, especially when self-hosting for a small-to-medium-sized group.

- It's tiring to read sites with all monospace fonts. I can see how it might be useful if most posts contain a lot of code, though.

- Do you expect this to be open sourced?

[drdruide]

As I said below, after several returns I've updated the site and removed the automatic deletion feature after 24h but I'm thinking of adding an option when creating a post. Thanks for your feedback, and I don't think it will be open source for the time being! If the site is doing well and there's a lot of demand for it, why not rethink!

[imska]

Wow, been thinking about creating the same thing for a while now. What did you build it with? I'd definitely love to see some of the code!

[curtisblaine]

Tbh the 24 hour horizon also means that you can do without a persistent db and store everything in memory (as managed db are typically the most complex / expensive part of the stack)

[thih9]

Only if you’re ok with an empty page after server restart.

[curtisblaine]

If it'a controlled restart, you can dump your memory onto a file when shutting down, then reload the dump when you restart. If it's a crash, yes, you will lose everything. Or you can do Append Only File persistence like Redis, in which case you won't lose anything in each case.

[thih9]

> dump your memory onto a file when shutting down, then reload the dump when you restart

To me this sounds like building your own db but worse.

[curtisblaine]

Agree for the dump idea, but AOF persistence is quite easy to do (literally open a file and append).

Of course you'll have to choose the right data structures in memory, but that can be ad hoc to your app, so considerably less complex than a general purpose database.

The only problem is when you go out of memory, but if you have an eviction strategy (i.e. a 24 hours life per post), you don't need to scale for a long time.

[thih9]

We’d still need code to load the data back, also to continously test that code (or debug in production), plus handle data migrations. There might be more use cases. Using a regular db might be simpler at this point, depending on the project’s setup.