The author says "it might be trivial for anyone to hack your server." "Might" is doing way too much heavy lifting here. Actually, the author has no idea if there is any actual exploitable vulnerability on the server. They just Googled a version number and fired off a "vulnerability report," which "might" be worth as much as the dozens of emails I get a month about "huge vulnerabilities" related to my SPF record, or those CVEs that boil down to "if someone has root on the machine they could do something bad on the machine."
I can't help but feel that the author's motivation was to get some sort of reaction, and now they've gotten it. If this vulnerability was so vital to be patched, why would it be bundled into a "by the way" DM on Twitter along with a post heavily criticizing the app developer? Both people involved can be idiots here.
To me, "what is it like to be a" is more or less the intersection of sensory modalities between two systems... but I'm not sure the extent of the overlap tells you much about whether a given system is "conscious" or not.
Pretty much the same conclusion here. Consciousness is what we feel when sheaf 1-cohomology among our different senses vanishes.
Bringing it back to bats, a failure to imagine what it's like to be a bat is just indicative that the overlaps between human and bat modalities don’t admit a coherent gluing that humans can inhabit phenomenally.
> Pretty much the same conclusion here. Consciousness is what we feel when sheaf 1-cohomology among our different senses vanishes.
There's something more to it than this.
For one thing there's a threshold of awareness. Your mind is constantly doing things and having thoughts that don't arrive to the threshold of awareness. You can observe more of this stuff if you meditate and less of this stuff if you constantly distract yourself. But consciousness IMO should have the idea of a threshold baked in.
For another, the brain will unify things that don't make sense. I assume you mean something like consciousness is what happens when there aren't obstructions to stitching sensory data together. But the brain does a lot of work interpreting incoherent data as best it can. It doesn't have to limit itself to coherent data.
I'll have to reflect more on the first part, but as far as
> It doesn't have to limit itself to coherent data.
There are specific failure cases for non-integrability:
1. Dissociation/derealization = partial failures of gluing.
2. Nausea = inconsistent overlaps (ie: large cocycles) interpreted as bodily threat.
3. Anesthesia = disabling of the sheaf functor: no global section possible.
At least for me it provides a consistent working model for hallucinogenic, synesthesia, phantom limb phenomena, and split-brain scenarios. If anything, the ways in which sensor integration fails are more interesting than when it succeeds.
Yeah to be clear I like this mental model a lot, and I give it extra points for invoking sheaf theory :). I was just saying it doesn't seem complete to me from a psychological perspective.
The way I look at it is that the sensors provide data as activations and awareness is some output with a thresholding or activation function.
Sense making and consciousness in my mental model is something that happens after the fact and it tries to happen even with nonsense data. As opposed to -- as I was reading you to be leaning toward -- being the consequence of sensory data being in a sufficiently nice relationship with each other.
Do you really mean that it's very nearly the same thing "To be a" you, and an Elon Musk, a homo sapiens infant, and an Orangutan? And only modestly different from these to be a dog or a horse?
If I've understood you correctly, I'll suggest that simple sensory intersection is way way not enough: the processing hardware and software are material to what it is like to be someone.
Glad to hear it resonated. And also glad I didn't start this project with the expectation of quick success, hype, or exponential growth. If I had, there's no way I would have made it through the slower early years.
We've done some pricing experimentation over the years, and it's possible we're actually still positioned too cheap right now for the value the platform provides.
Personal finance is a pretty broad space, and it's common for different people to come to this with varying desires and expectations.
In our experience, the people who see the value in a good long-term DIY financial plan view our current pricing as extremely affordable, especially compared to traditional financial planning services which often charge $3-5k for a PDF and a pat on the back.
Anyway, if automated tracking is the piece that's most important to you, it might be worth noting that we do plan to add more options for that. But that work -- and all the other controversial implications of it that I mentioned in another comment -- just needs to be prioritized against all the other highly requested things on the product roadmap, based on what the community really wants the most.
I noticed most tools neglect international scenarios because the US market is big and it's easier to focus on that. So I decided to be different and try to build with as much international flexibility as possible. We have a bunch of international account types and tax preseta, including some for the UK.
Probably a couple of hours on support per day on average, some days less, some days more. The vast majority of users don't ask for support, they prefer to read the docs, read the community forum, goggle stuff or hunt-and-peck options in the app. Roughly 90% use the free version. If everyone used the paid version I could have a very large team, but the reality is the product competes with many free tools.
If you update the app or refine docs in response to previous support questions it does streamline the experience but there are always folks who just don't read docs and there are many who will purchase the app just for access to support so they can figure something out.
I'm sure some apps are more support heavy than others, but ours is aimed at system administrators and with that comes an assumed level of competence (in reality, many people are only in the role because nobody else could/would do it but even they are quite independently resourceful).
The disadvantage of users helping themselves is that you don't get feedback from them or learn about their use cases. Knowing how/why people are using your stuff is really valuable for development, so if I had the team for it then dedicated support engineers would follow up with customers early on even if they don't have issues.
Did you consider adding an optional survey (or just an input or two) somewhere in setup or the onboarding flow? I bet some % of people would willingly tell you how/why they are using the software.
Maybe I missed it, but was it ever established that these general vulnerabilities are actually relevant to this specific system/implementation?