public/design.md

::: header

design

:::

::: section

Steps

1. Good design leads to good software. There are three main parts that need to work together:
   1. Technology: This is the foundation. Bad theory leads to bad design.
   2. Interface: If the interface is clunky or annoying to use, it won't be used.
   3. Humans: It needs to complement human tendencies. Don't encourage bad habits.
2. Implement your design. Don't bother with perfection, instead make it only complete enough to be usable.
3. Test your design and look for weak spots. If you find any, do a quick repition of steps 1 and 2. If you think your design is flawed, take a moment to think about it - some parts may be salvageable.

Tips

1. Build for yourself. Don't worry about what other people think. Some of the best software is designed and used by only one person.
2. Try to be extensible, being able to adapt to any needs.
3. Try to be composable, being able to work together with other stuff.
4. It's better to have the three parts of your design complement each other than have one get all the attention. I've seen flashy interfaces that don't work, incredible ideas that aren't implemented, and cool technology that is unusable.
5. Not everything needs to be implemented. If you have a good idea that doesn't fit, write it down in a "ideas for later" or "sequels" notebook or document.

Ideas

With that being said, here are some ideas I've had. It's my sequels page, and feel free to take as many or as little as you want! These have both random fragments that can be integrated to larger projects, or large projects on their own. There they are in no particular order:

1. vote tagging: Think of this like chat reactions for tagging posts. Instead of the creator or moderators tagging their post, other users do the tagging. A good news post could get many #news reactions.
   1. negative tags: Instead of only being able to upvote tags, it's possible to downvote tags.
   2. tag pages: You can see the newest, hottest, top, etc tagged posts. Each tag forms its own ad-hoc subreddit-like group which can be subscribed to.
2. subjective moderation: Instead of a few moderator actions being canonical for everyone, people can subscribe/unsubscribe from someone's moderation.
   1. filters: You could combine block/approve lists into collections of filters. This doesn't need to be for moderation and can also be ie. "show me funny posts" or "show me posts about $topic"
3. your world of files: A social media platform where instead of sharing posts, people share files. Kind of like a shared drive.
   1. as a blog: People could be authorized to write to their own files in subfolders, ie. have posts/hello-world/hello.md and posts/hello-world/comments/ where people can write comments.
   2. as a wiki: Maybe file changes could be tracked, and people could create shared wikis
   3. as a repository: This could be used like a git repo, where you have a code/ folder with issues/, patches/ (prs/mrs), discussions/ and so forth
4. logical inbox: Some kind of software that combines inboxes and notifications between many other platforms into one platform.
   1. like rss: Rss is wonderful, but unfortunately not supported everywhere. Something that converts email to rss or gives an http api would be nice, where it could then be added to the inbox.
   2. chat segmentation: Take a chat log from {discord, slack, matrix, etc} and split it into topic-based threads for the inbox.
   3. all the comments: Find a way to combine comments and their ranking/scores from many different platforms together.
   4. semantic deduplication: Sometimes you can get repeats in multiple places. Being able to deduplicate and merge comments, replies, activity into one entry would be incredible.
5. language model functions: It would be wonderful to have a server that lets you create "functions" to process and transform text. It could let you finetune t5-base to do whatever you want, and expose and endpoint for "calling" it as a function.
   1. model library: Maybe have a registry that people can publish stuff to, ie. "extract recipe json from html" or "summarize text".
   2. other models: t5 has an insane payoff/speed ratio, but I get that sometimes you need a decoder-only model for long running interactions.
   3. serverless, but actually: The server could let you export (quantized, distilled?) models (maybe in onnx) and let you run them where they need to be.
6. find everything: Some way to find everything on your computer.
   1. now with semantics: Index the embeddings of media like images, audio, and video instead of only subtitles/ocr
   2. custom google: Search the web by crawling specific domains or using an index, maybe from some kind of index repository
   3. history is important: A way to do a full text search across all the websites you've visited, maybe combined with "logical inbox" above
7. rust x typescript: This would be my ideal scripting language. Rust is great, but needs more work to setup and prototype in. Typescript doesn't have match or enum. I'm not sure whether borrow checking is good in a scripting language or not, but having some way to check how data moves is great.
   1. easy ffi: It should be easy to move from a small script into rust, or rust to the small script.
   2. raii: Even if there isn't any borrow checking.
   3. targeting wasm: I think webassembly is a perfectly cromulent target.
   4. or a minimal runtime: Alternatively, it could be easily embeddable.
8. language design: These are a some ideas that could be integrated into programming languages.
   1. fn main(ctx: Context): Main takes a context which is the gateway to all io and side effects. 3rd party modules can't access the filesystem unless you explicitly pass ctx.fs. Different contexts exist for different platforms.
   2. rich stdlib and extlib: The extended library extra useful and well supported stuff that shouldn't be in a minimal stdlib, like sqlite or images
   3. tabular tables: A helper around struct-of-arrays. It's meant to be a dataframes replacement, but does have nice things like joins and views into the table. Maybe like C# and linq, but less baked into the language.
   4. content addressing: Packages are content addressed, like with ipfs. (see scrapscript?)
   5. time management: Dealing with time is hard because you're dealing with a localized format. Stdlib only deals with unix time, with extra libraries to do intl (ie. Temporal::new().with_timezone(...).with_calendar(...).with_format(...) which is used for parsing and serialization). You can only do things like "get the day/year" with the extra library.
   6. layered cloning: .clone() is implicit and automatic, and is a mix of cow/arc/references.
9. helpful documentation: I think some projects, like nixos, could benefit from better documentation. But there are also entire areas that need better docs.
   1. debugging: How do you debug? How do you use a debugger? A lot of people still resort to print() because debuggers seem too foreign.
   2. performance tips: Too many people focus on things like Big O notation, while low hanging fruit with greater effect are untouched. Optimizing memory access and batching/vectorization, for example, are pretty useful to understand.
   3. computers in general: This isn't ain't your grandma's book. These are things like staying safe online, using software, and making computers work for you. While I do think things should be improved by design if possible, I also don't people should use fisher-price computers. People are smarter than you think and will read helpful and consise documentation if it exists and is readily available.
   4. writing: There's so many holes for educational resources and so many people who could write helpful docs for it, but that won't happen if technical users don't know how to simplify their writing for the noobs. :::