i do have. and my 'sms' goes over it. but i can't make everyone come to me. (i did abandon the ones who are whatsapp-only tho)
pootriarch
joined 2 years ago
When I installed Signal it complained that I didn't have Google Play Services and fell back to websockets. But my phone is boring, I do have Google services. Could I have something in a firewall config that made it pick wrong? Is it using a different checking mechanism from all my other apps that go through FCM?
Unfortunately this is a non-starter for me at the moment.
- Molly/FOSS/UP is deprecated and frozen at a prior version, so I'm at risk of vulnerabilities.
- Upgrading to current Molly-FOSS requires a VAPID-capable mollysocket (1.5 or higher).
- mollysocket cannot be upgraded with a simple cargo install. cargo throws
error[E0599]: no function or associated item named ec_gen found for struct PKey<_> in the current scope
Searching for PKey::ec_gen() points to openssl. mollysocket has at least two dependencies that it doesn't declare, but we don't know how many.
You probably need to install some system packages, like libssl-dev libsqlite3-dev.
The best-case scenario is that libssl-dev is a lower version from what it wants, and that an upgrade would clear the problem. But since the dependency isn't declared, we don't know the minimum version. In my case it doesn't matter as I'm in a shared hosting environment and I can't just change system packages.
I'll need to figure out a way to go back to vanilla Signal, and a way for Signal to recognize that I do in fact have Google Play Services. The Molly docs explain only moving to Molly, not away from it.
i surely didn't explain well. to my knowledge there are three mollys. the standard one with google services blobs, the -foss that has no blobs and presumably has to use websockets, and the -up (-foss-up?) that can do unified push, though it doesn't have to.
i forget whether foss and -up were in different repos to each other. but without my changing any repos, molly(-foss)-up updated itself to 7.23.1-1.up1-foss. this is behind the 7.26 of -foss. it displays a dialog that says it's deprecated, and since it's left backrevved, isn't likely getting security updates. clicking install sends you into the hole i described at first.
i do believe this path is working and that my notifications are coming through my xmpp account, not websockets. but i haven't traced it to prove it is so.
OK, the VAPID key is new and it's mentioned but not documented (other than to say it's used if 'it supports it'). Is Molly now dependent on the QR code and VAPID for configuration (meaning I couldn't attach it to the pre-1.5 mollysocket that I have now)?
thank you! i have to look at mollysocket then; i don't remember the vapid/qr step, so might have to upgrade it also
it's not a cap, it's that the monthly fee covers 120 mins. overages accrue per-minute charges, but if you're routinely needing more than 2h talk time, jmp may not be the best answer
q21 on https://jmp.chat/faq
Every JMP plan comes with calling credit, worth approximately 120 minutes within the US & Canada, included in the monthly price. By default accounts are set to be warned when this limit is reached so no one gets any surprise charges without getting permission first. You can adjust your plan settings with the bot to raise this limit and allow your account balance to be directly billed for any minutes over the included amount.
per-minute pricing: https://jmp.chat/pricing/USD#US
i'm no expert — consensus sounds like putting disused only on the main tag, and when i've encountered this, i haven't marked anything disused at all. i've only looked at the stop/platform to make sure they weren't in any relation (transit line relations may include the passing way but shouldn't include the disused stop/platform). and i make sure route_ref isn't set on the stop/platform. were the stop to be used again, i figure it would have the same ref/stop id and operator, so i don't remove them. listening for better ideas though
I'm torn, because on the one hand, yes! — the hour I spent figuring out which PGP XEP was the right one is an hour I won't get back. But, "only the XEPs you need to implement for a modern messaging application, ignoring historical cruft and excessive backwards-compatibility" sounds so much like the beginning of an extend-and-extinguish cycle.
thank you… more of a thought experiment now than a true need, but it seems like if it became a need, i'd be better off building a matrix account. i suspected this but had hoped for more :/
OSM has a lot more data inside than the website shows - in dense shopping areas you can't zoom in far enough to see all the POIs, much less business names.
I've read before that using cached previews was done to stay accessible to less-powerful mobile devices, which would have smaller CPUs that would be taxed by rendering the native vector data. I view it as a branding disadvantage that OSM appears, from desktops, to have less info than alternatives. But that's a battle that's been had many times before, one might as well argue over paper vs plastic.
view more: next ›
I have the Multiling keyboard. I don't recommend it to others as it's rather long in the tooth and still has quirks I haven't fully sorted. I keep it precisely because it does multi-language support with separate dictionaries; I switch it between U.S. English and French Canadian and autocorrect follows. It's massively customizable but I don't understand it and am more likely to render it unusable than to make it better.