A little cool tech detail, I didn't want a backend or to store the information of people's reports anywhere. To get around the requirement, I made the form deterministic and populated on load from a data stream of bits (form is made from booleans or bitfields) from a decoded base-64 query parameter. A cool side-effect of this approach is I can update the query parameter in the URL in real-time as you fill out the form so if you reload it remembers your form without any local storage or cookie use!
They're used quite frequently in the UK in bars/pubs where there are several people serving drinks and (I assume) there's some metric tracking by management on till use.
They're used in various hackerspaces around the world for membership administrivia .. Metalab in Vienna, for example, uses them as a door lock mechanism ..
Woah! The world really works in mysterious ways. I've found myself thinking in this space a lot recently. I've been working on a pager that takes the notifications from my phone and relays only the ones I want to see. I use LTE-M/NB-IOT to get connectivity anywhere and the device works and I'm looking to find a way to get a pcd/case made..
Your project seems really cool and allows you to bring your own hardware. Out of curiosity, have you blocked all notifications on your phone? Would this be run on your computer? Would you ever move in the direction of a physical device?
Heh, that is exactly why I kept UDP-7777 passive. It listens on 0.0.0.0 but sends zero telemetry and requires no "online" status packet. Unless you hit ACK (which sends a packet back), you are a ghost.
Just took another look at your work, and your LTE-M project looks incredible. The e-ink aesthetic is exactly right for this. I've fantasized about building some apps for e-ink displays (wanted to drop BrowserBox in a remarkable tablet, etc), but haven't yet. Here I stuck to desktop/software for v1 to solve the immediate 'screen fatigue' issue, but I'd love to see a world where physical tokens like yours replace the smartphone notification center.
Yes, I block all the notifications on the phone. I leave badges for some apps and check when I want, or just periodically check when it's in my rhythm. (A few people have exceptions). It runs on computer now, but the next step is I want to test if mobile could be achieved without a server (I'm okay with a Tailscale/ZT requirement or such, for now). Aside from that I would love physical infra. If it could work such that it piggy-backed off existing infra, at first, might be good approach. Someone should do this. I don't know if it's us, but it should be created.
If anyone would like to discuss these possibilities, please reach out at pager@dosaygo.com
Yes! I really want a physical device for things like this. It's cool we are both thinking about it: independent invention. That is a sick website. Love the design!
Feels very similar to Digital Gardens - something I've been doing to hit all the same points! (Shameless plug to mine as an example https://launchbowl.com)
This product does provide a bit more of a structured approach without any of the self-hosting/coding difficulty which I think would have a wider market appeal.
Ha! Very cool! I did not know about the community/idea of Digital Gardens! From my quick glance, it seems close to a lot of my thoughts.
I like what you have done with Launchbowl! The part about linking multiple posts together is something I swear by for personal writing & note-taking on Anytype. Graph is a very efficient way to process a lot of connected information!
Thank you! Yes, Jottings was built for anyone, even with no tech experience, to set up and have a site where they may post their thoughts to the world.
This is the first time I've read this but have personal experience similar. A few of my single page, gone nowhere, projects are seeing ~2k views a month. They're seeing zero traffic through google in that same period so no idea where it's coming from?
This is something I've been thinking about a lot recently! My friends group all seem burnt out by the direction social media is going, with what you're building seeming like a better return to the norm. Will follow along to see your progress!
One thing that kept tripping me up when thinking about this was pricing - everyone is so conditioned to think that social media is free that this will be a huge hill to overcome. Your pricing, although I think if done right feels very fair, instinctively makes me recoil a bit.
Yeah, even calling it anything close to "social media" turns some people off. And most people are totally fine using group chats or DMs — which are free, for now.
It felt weird paying for email after using Gmail for so long. Even now, most people do not care enough in order to justify paying for it. This feels similar.
We can't afford to offer free-forever accounts to everyone - not without compromising on principles. But we are thinking of ways to make it more accessible at least for some people. Open to ideas!
The "social media" baggage, and the pricing bit you pointed, those are definitely the two biggest challenges imo. If this was not something we needed and used ourselves, we probably wouldn't have built it.
> There is little protections against messing up with the internal. This is on purpose, I want the kids to learn to use the API not mess up with the internals of every single class.
I don’t understand the reasoning; you’d add protections if you wanted them to learn to use the APIs. You’d remove them if you wanted them to mess with the internals of each class.
That's a bad strategy. The reason people are tempted to mess with internals is that it works most of the time. Unless the library has some way of punishing people who use them, then they'll just do it without regard for, as far as they're concerned, arbitrary toothless restrictions. Sure, some stuff will break, but that's true even if they're respecting the API boundary too, especially for a beginner. There will be zero learning about API boundaries in particular.
I think it's fine to encourage beginners to engage with the internals of an API and do things that are unwise. The goal is educated pupils, not successful or maintainable projects. Let them play in the mud and get dirty. I think the idea that code is something that can be experimented with is one of the most valuable lessons, and breaking things is frequently the path to learning how they work.
Maintainability is one of the finer points that can come later.
Games are notorious for vendoring a dependency and never upgrading it again. If you use an internal API, it is not like you are forced to be on the upgrade treadmill where the sands suddenly shifted and the secret API does something different.
They mean that their code is written with strong assumption everything is written the way it is. If you make modifications to the internal or push an unexpexted type in it, they expected it to fail. There's no guardrail that everything is in a right state.. well, standard internal code.
I was on Slack one day and there were multiple time-critical issues ongoing within a channel. It became difficult to keep track of who said what and in response to whom. In the aftermath, it was decided that threads should be the sole method of organization. In the weeks following it was clear that best intentions don't change habits overnight, so I hopped on Slack's app directory and searched for a solution. Existing solutions were priced weirdly or were too expensive for what was needed, therefore I built my own!
I would be interested to hear if this has been an issue for others and if something like this would be useful. The idea with this application was that people only need a light reminder or guide for their habits to change and Slack already does all the heavy lifting as an amazing messaging tool.
https://disclosure.launchbowl.com/
A little cool tech detail, I didn't want a backend or to store the information of people's reports anywhere. To get around the requirement, I made the form deterministic and populated on load from a data stream of bits (form is made from booleans or bitfields) from a decoded base-64 query parameter. A cool side-effect of this approach is I can update the query parameter in the URL in real-time as you fill out the form so if you reload it remembers your form without any local storage or cookie use!
reply