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

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.

The main URL points to this:

strangest thing. i updated firefox and now i have no notifications. only a limited number of sites have notification perms; they still say they have that permission and my system settings still have firefox allowed. i have another machine running ubuntu (with firefox from the PPA for apt) and notifications are unchanged there.

Prerequisites

• Internet-facing web server with reverse proxy and domain name (preferably SSL of course)
• Server behind the reverse proxy with Rust environment

Installation

• Don’t bother downloading the source code to your server; installing it that way gives you a big debug executable
• Instead just cargo install mollysocket
• Move the mollysocket executable if desired
• Run mollysocket once so that it will emit the default config

Configuration

• Fish the config file out of .config/mollysocket/default-config.toml and copy it somewhere.

config.toml

• In the new file, replace the allowed_endpoints line with allowed_endpoints = ['*']. The default 0.0.0.0 config appears to be a bug; this setting controls access to endpoints within the app, not IPs from outside. Leaving the original value causes mollysocket to reject everything.
• Put a proper path in the db = './mollysocket.db' line rather than just having it land wherever you’re sitting.
• Delete the mollysocket.db that was created on first run (even if it’s already where you’re intending to put it). This is just to make sure the web server creates it and has the correct permissions.

Run script

• The environment variable ROCKET_PORT must be set or the server will sit and do nothing. It’s best to create all of the environment variables mentioned in the README, whether that is in a user profile script or in a shell script that wraps startup. You can change any of these values, but they must exist.

• export ROCKET_PORT=8020
  export RUST_LOG=info
  export MOLLY_CONF=/path/to/your/config.toml
  

Proxy server

• You’ll need to proxy everything from / to your mollysocket server and ROCKET_PORT.
• Exclude anything that you may need served from your web server, such as .well-known.

Things to know

• I get this warning on startup: “Forced shutdown is disabled. Runtime settings may be suboptimal.”
• I also can’t stop my server with any sane signal; only SIGKILL brings it down.
• Some discussion here: https://github.com/SergioBenitez/Rocket/discussions/1880

deleted by creator

you probably already found this, but for others who might be curious:

https://molly.im/

https://github.com/mollyim/mollyim-android

in the settings if you change notification method from websocket to unified push, the UP settings come up, including a server address (which is what they intend to be used) or some air gap mode that i can’t find documented

part of humans learning to drive safely is knowing that flouting traffic laws increases your chance of being stopped, fined, or if you’re not the right demographic, worse things. we calibrate our behavior to maximize speed and minimize cops, and to avoid being at-fault in an accident, which is a major hit to insurance rates.

autonomous vehicles can’t be cited for moving violations. they’re learning to maximize speed without the governor of traffic laws. in the absence of speed and citation data, it’s hard to measure how safe they are. there is no systemic incentive for them to care about safety, except for bad press.

again not foss so won’t dwell at length — but i use fund manager from beiley software. commercial, but works double-entry and handles more investment complexity than a human could ever need. windows app, i run it under wine on linux and crossover on mac. (i don’t own a windows box — that’s how irreplaceable it was for me.)

asus pn51, a mini nuc-like box

so per wikipedia and confirmed at MDN, firefox is the only major browser line not to consider certificate transparency at all. and yet it’s the only one that has given me occasional maddening SSL errors that have blocked site access (not always little sites, it’s happened with amazon).

i don’t understand how firefox can be simultaneously the least picky about certificates and the most likely to spuriously decide they’re invalid.

well i feel stupid now for not doing the obvious. but…

Blocked Page

Your organization has blocked access to this page or website.

on the PPA box, this is what it showed me (meanwhile it was attempting to connect to incoming.telemetry.mozilla.org). another symptom of displaying respect for enterprise policies but in fact ignoring them. (as i had mentioned, on this box all of the settings look locked down as they should be, but it’s still attempting to send telemetry.)

thanks, i’ll look again. it’s not that i love the idea of being fingerprinted; i just think that five mylar bags, four tin hats and a partridge in a pear tree won’t save me from that. i need my password manager, and once that’s in, enforcing a generic screen is silly - cow’s out of the barn. but not having the arms race against pocket and telemetry would be a big bonus.

i did try that but the never-dark mode blinded me. i understand the reasoning, but absolute anonymity isn’t my own threat model; i’d like to be able to use themes and resize the window

an interesting oddity: on my non-rooted xperia, signal thinks that i don’t have play services and so it falls back to… polling. every five minutes. killing my battery and my logs.

i had to put signal into the restricted battery group, which means no notifications. i anxiously await the new molly, as i already have a unified push environment. it looks like the migration will be a bit delicate.

i have wired sennheiser momentum 2s. the momentum line is on 4th generation now, and they look to all be bluetooth.

mine are great for use on the train, or the plane, or in bed for not getting hit with a pillow. fed from a phone, they’re a little weak in the bottom end — probably an impedance thing — but fed from a headphone amp they’re ace. (though it then becomes possible to leak enough sound to get hit.)

they’re not active noise-cancelling and they’re not sold for high isolation, but they keep enough in and out for any of my needs. and impedance matching isn’t an issue when fed by bluetooth, though then they’ll need to be kept charged.

It exists, it’s called a robots.txt file that the developers can put into place, and then bots like the webarchive crawler will ignore the content.

the internet archive doesn’t respect robots.txt:

Over time we have observed that the robots.txt files that are geared toward search engine crawlers do not necessarily serve our archival purposes.

the only way to stay out of the internet archive is to follow the process they created and hope they agree to remove you. or firewall them.

https://blog.archive.org/2017/04/17/robots-txt-meant-for-search-engines-dont-work-well-for-web-archives/

i am not sure it’s a flaw at all. the conditional tag syntax is based on opening_hours, which should be able to express ‘closed at these times until that date’. there are ways to finesse this. but as long as the published guideline is ‘don’t do this’, there’s little point pondering practical solutions.

Our map data is often downloaded and used offline on various devices for several weeks or months. For offline data to be useful, it should at least be expected to remain unchanged in the next few weeks when you map it.

yes, by this blurb, concession for offline users does supersede safety.

i’m an editor active enough to have been granted foundation membership but hadn’t known this rule; it indicates a view of osm as analogous to a paper map rather than for real-time navigation. if a change of less than weeks’ length is discouraged, i can’t in good conscience steer my friends away from google maps, as navigation is not a primary use case.