From d5713de87562af69812c1f67e75fc732535879d9 Mon Sep 17 00:00:00 2001 From: tangent Date: Thu, 10 Sep 2026 19:57:54 -0600 Subject: [PATCH] Add Brainstorming.md --- Brainstorming.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Brainstorming.md diff --git a/Brainstorming.md b/Brainstorming.md new file mode 100644 index 0000000..c8cdb14 --- /dev/null +++ b/Brainstorming.md @@ -0,0 +1,58 @@ +This is imported from notes I took on my phone on [[2026-09-08]], near 14:00. + +## Tables +- Posts + - id, share_summary, above_fold, main_body, created_at, updated_at, published_at, view_status, view_count, url_slug, user_id, scheduled_at, parent_id, password_hash, +- Users + - id, password_hash, user_name, created_at, updated_at, display_name, +- Comments + - id, user_id, post_id, created_at, updated_at, main_body, view_count, parent_id, url_query, display_name, +- Notifications + - id, user_id, created_at, updated_at, view_status, +- Pages + - id, main_body, view_status, created_at, updated_at, published_at, share_summary, view_count, url_slug, scheduled_at, parent_id, password_hash, +- Views + - id, object_type, object_id, ip_address, created_at, updated_at, user_id, + +~~What if posts/comments were the same? Using parent_id to specify origin? Kinda like the reddit-like idea I had before? Can that scale or will it cause problems? Why should I care now?~~ + +~~There is a lot of overlap between posts, pages, and comments. If I did a parent-based system, it would also be useful for organizational hierarchy.~~ Pages can be automatically organized in URL scheme, menus, and tables of contents if they just have parent ID. Same with posts if a hierarchy is desired. + +A URL slug will be ~~a fragment instead of an entire path? No, because then URLs can change when stated hierarchy changes, and~~ consistency is important. Slugs should be set once. + +~~If we do "all content is one object type", that object should have a type field? Yea, it's necessary for style, how else would it know whether to display as part of another page or a separate page? How would it know whether to place it in a menu/ToC?~~ + +~~To replace my blog, I'll definitely have to in effect reserve a lot of slugs if I make this in a way that implicitly allows other blogs. I think that idea is too ambitious.. but gosh do I want to try!~~ + +~~Object types: post, page, blog, comment~~ +~~What does a blog need to define itself? It needs styling.~~ + +I need to NOT do the everything is an object route. It's not worth the theoretical advantages. + +Comments have a url_query instead of a fragment or slug because they need to not interfere with the structure of posts and pages, and need to be sent to the server to display correctly if I end up with an automatic scoring system that can push comments to other pages. (This also means that comment pages should be in the query imo. I think the query part should be for more ephemeral things on here?) + +Comments have a user_id and display_name so that anyone can post with a different name on any comment instead of just using their display_name, ~~and that also allows for a default anonymous account to have any name on any comment but still be clearly posted without an account.~~ + +Users have a display_name so that non-unique names can be used. + +Editor interface needs a live preview, so I'll use marked.js for that I think? Should be contained in an iframe and loaded from a special URL so that broken code doesn't break the editor. + +Instead of one anonymous user, when someone comments, use a cookie to recognize which account they're using. Call it guest instead of anonymous, and point out that posts will be associated with each other. + +I decided to give posts and pages parent_id so that more interesting blog hierarchy is possible. + +Somewhere I need to explain anonymous view tracking, ~~specifically that hashing is used to keep addresses private. No, this isn't good enough because it is trivial to find the hashes because there aren't that many IP addresses.~~ I think I should do it anyhow, but with regular address purging, combined with Geo IP guessing for stats stuff. This is all down the road stuff. + +I'm trying to think how to efficiently handle the menu. It should be cached in a simple format - so let's say the complete HTML to just stick into the page raw. But it also needs to be generated from something, I was thinking each item should have an order field, but that's too cludgy. It shall be a JSON object, and needs another live preview type editor to verify correct changes before saving. + +~~Cache whole pages as much as possible instead of fragments.~~ + +--- + +~~It should save space and caching fragments would still require too much processing?~~ But I want live view counts, which is incompatible with whole page caching. + +view_status: public, unlisted, password_protected, internal, private, scheduled_public, scheduled_internal, scheduled_unlisted, scheduled_password_protected, + +~~Instead of having several scheduled types, just have the scheduled_at and view_status TOGETHER define visibility? That makes it less tedious, but easier to make a mistake.. I could use a separate field for subtype instead, but that would also suck.~~ + +This design can leak information about a page's existence based on server response time to a slug, as it processes whether permissions exist. I'm fine with that, but need it stated.