"Hmm. Not sure. Maybe google it?" is pretty innocuous no matter the context.

"Hmm. Not sure. Maybe look it up?" can sound dismissive or condescending in some cases to some people's ear.

It's a weird quirk of English where being non-specific is like saying "I don't know, you figure it out", where being very specific is like saying "Here's the solution (that I would use)".

I realize it's not the most efficient way to work, but I like my code to read like instructions. There's nothing reduce will do that a for loop won't accomplish and the for loop (+ an accumulator, of course) is more clearly "readable" than reduce. If I read map, I know what's going on. If I read filter, I know what's going on. If I read reduce, I have to figure out what's going on, even if I'm pretty sure what is going on. If I could rely on reduce to always give me back an element of the input array, I would use it more. But since it can give back anything, I prefer the simplicity of a for loop.

[0] I don't have any suggestions for "better" names because the whole operation is hard to sum up in a word? "dispatch" makes sense, as a function dispatching a function over each element in an array, but it masks the concept of accumulation from return values. "transform" is accurate, but hardly descriptive at all. the list goes on. It's an undeniably useful little function, it's just hard to make it easy to understand and therefore debug.

You really should listen to me. If you need some time to think it over, I understand. It's a lot to consider and you've got a lot in your plate. I'll check in soon - would tomorrow be okay? If you need more time, just tell me when.

vs

You really should listen to me. I'll give you a day to think it over before I take further action.

Same information, but the latter assumes a position of authority (I, the person in charge, will be the provider of the time you will receive), and then uses that position to provide an ostensible benevolence as a way to mitigate the implied follow up of non-benevolence. The threat is introduced as the power disparity. The person in power has leverage over the less powerful and the threat is that they will use it. Remove the power disparity, and the implication of threat is also removed.

Tailscale just moved up in my priorities list. Was going to host my next website with hostinger, but now I'm going to at least try to run a personal server with tailscale to make it public. I might not be able to figure it all out, and may end up going with the VPS route, but this gave me some appreciation for the company that makes me willing to try the less familiar method.

If nothing else, this blog post certainly invites scrutiny over how much feelings affect what classifications feel comfortable.

Though, I will admit that I never include cooking in that. Food, for some reason, has never felt, to me, like "content". Can't say I've ever interrogated why.

I don't particularly like the term "content creator". It feels too blunt and sterile to be particularly useful. But it does seem to be generally useful in how wide-reachingly descriptive it is.

I know hosting an entire sign up process and user content is not something you can just build and forget about, so my thought was that a sufficiently decent website could bundle a package that could be hosted on existing organization infrastructure. A zip file of the user's content that they could upload to dropbox/drive/sharepoint/etc. Then the consumer page would match a url slug to a package file and serve the content that way.

It's... a lot of stuff for a quick workaround project. And it's a pathology of an engineer to make solutions where solutions aren't needed. So grain of salt on any of that. But I did want to clarify since you were willing to engage with the concept, as understood. Hopefully this proposition strikes you as less concerning/illegal! I never want to steal anyone's work or infrastructure. I just believe that better alternatives - even ones borne of seeing how badly other people are doing it - can and should win out, if people ever provide them.

One criticism, though: I wish you would have made a simple form-based alternative to the app's population mechanism, rather than just make the one-off consumer for yourself(/those you shared with). Definitely way more work and not something you should have to do. But that would have been a cherry on top. Not only prevent needing the app for viewing, but also removing future incentive for an organization turning to an app like that in the first place.

Honestly, though, I'm most intrigued by your P2P solution. I've built a couple of web apps as custom html elements that use indexedDB for storage and I've been trying to figure out the sweet spot for syncing the data between apps. I think this nostr relay hits the mark as something people can feel comfortable not self hosting, while power users can host their own solution. Seems like a great solution, to me! Any advice as to some footguns with the approach? I'm very interested in giving it a try myself[0], so any notes you think would prevent some re-work would be really appreciated!

[0] as a public domain/oss-licensed module, if there's a reasonable method of packaging it as a standalone library

Since you've actually started a social media site, I wonder if you have any insight on that? You say you believe in this project; what is it that you think is valuable about letting everyone talk to everyone, as opposed to exclusive and curated spaces for people that semi-self-select based on community interests and values, like forums? Separately, why do you think that removing organizations/brands and psuedo users is going to be the crux of the solution?

Honestly looking to have my mind changed. But mostly just curious.