That happens when public uses it, en masse, in the first place. And as it is today the "public" has no reason/incentive in switching to it and that naturally keeps the "non-technical public" away from it.
So who is this serving eventually? A very few, mostly "technical public", in complete contrast to what you have said.
I suspect Signal's goal is something entirely else. For them it's just two things:
1. Some sort of shallow ideology (started with the founder and the flame kept alive by the later leaders who often come across ideological groupies; the last bit is a bit strong but whatever)
2. Executing based on that for the sake of executing that because they can
What their intention is not: Signal ever becoming IM app of choice anywhere and possibly they might have their reasons for this. One of those reasons could be affordability as you have said it.
Note: in case this wasn't clear, the moment you attach a "phone number" you make it inherently unsafe for most, like 99.353959353%, of "general non-technical public" to use Signal and remain really unidentifiable. Once they are identified - in most countries (and now even in places like USA it seems) only thing needed after that is being "picked up" and rest will be just sung even without a device. I mean it's so absurd to even not think about it is that it's ridiculous. So no, it is DEFINITELY not "non-technical public can use".
> And as it is today the "public" has no reason/incentive in switching to it and that naturally keeps the "non-technical public" away from it.
I know plenty of non-technical users on Signal. Based on news reports, it's used widely by activists. I see journalists advertising their Signal contact information for tips. It's recommended government-wide in the US by CISA and is pre-installed on US intelligence community computers, including in the CIA.
I don't know what you tried but I tried to do something in Pi what I'd have usually done in Claude and it devoured tokens (much more than Claude) and I wasn't even close to finishing the task. Mostly because the barebones Pi was/is very inefficient at anything with any weight.
Then I began to customise it to be as good as Claude but eat less taken. I got tired and I had not even scratched the surface. Gave up.
I finally realised, at least for me, Pi's best use case is - strip even the little "extra" Pi comes/starts with and then use it just like that if you have a task/work that is appropriate for that bareness.
The trick to use Pi is you use it in N ways if you have N use-cases. You need N set of shortcuts/plugins/aliases etc for that. Can get tiring at times.
So I keep Pi for just one case - when I have to easily strip everything out for some work. Anything heavier and OpenCode or Claude are ones. I am sure I can make Pi behave as I've suggested above the "N harnesses within 1 harness" and I even tried but it simply started getting out of hand and using the harness started becoming the frustrating hobby.
As for OMP, I just don't understand why would anyone use that not Pi or other "full-fledged" harnesses.
This looks like such a nice cli/tui talking/chat harness - an agent with which I can work on non-coding tasks (where it literally doesn't need any tool - maybe a read tool for few files in that folder, or not even that) - writing critique (w/ strict strict for on generation/suggestion), analysis, summary etc.
I've been so far using pi like this:
> pi --offline --no-extensions --no-skills --no-prompt-templates -nc -nt --thinking low --system-prompt "$(cat <custom purpose path for system/role prompt>)
Purpose was to reduce token usage to an absolute minimum (zero extra token) as often I use this per use API keys (and not my GLM key, which let's say, is a bit "different" when it comes to conversations).
Are there any other tools specifically designed for such tasks? Even though hax looks like the absolute bare minimum one can go while still being usable.
I wish there was also tools that would refuse and reject (or prevent) models from inserting "thinking" messages into responses. They keep appending those and that very soon that part starts snowballing on steroids.
Few of the biggest reasons for "migration" to the likes of React Native, and web-views et cetera, were "lack of talent", and not getting that talent fast, and for cheap, et cetera, while of course terming that as innovation, embracing the future, and "that's where the game is at" et cetera. Now with the LLMs that is mostly sorted. So if anything I'd be able to see the eradication of the Electron infestation in my lifetime. But then I see the very tools these LLMs are accessed with i.e harnesses (and of course mostly made by the LLM houses) are made of Electron or similar things (sometimes a Frankenstein like mix). And even today Claude Code shows up as `2.x.yyy` for process name ffs! So if anything, this is getting worse.
Then they say:
> We decided to switch from native to React Native in 2020 for three reasons:
> Stop building the same features twice
> Allow developers to work across the stack
> Spend less time chasing feature parity and more time shipping value
Totally!
Is there some kind of shame in just saying:
- we didn't want to hire more people
- we didn't want to pay those salaries
- we fired a lot of engineers with move to react native/hybrid in mind
- we could reuse the frontend devs (aka "full stack" folks) with or without some extra whippings ensuring they grok the bare minimum they'd need to build for mobile and test in on mobile.
Well, good for Apple — at this point if they released an actual brick (I mean an actual clay brick), wrote a few Applesque things on it, showed it on stage, said stuff like "First Ever Apple Brick™," and priced it at, say, $399 (that's a conservative estimate), they still wouldn't be able to keep up with the demand. So, your loss.
reply