robryk @robryk@qoto.org

@mcc @zarfeblong

Note that "not publishing lists of followers at all" is something that's supported and iiuc considered perfectly fine.

I don't see how knowing that "X is hiding their followers" can help you with determining whether Y is a follower of X.

Yes, I agree that this is a game of increasing friction. However, friction for people doing things manually is very different from friction for people using any kind of automation, so I think they need to be considered as two distinct problems.

@Flyingmana @realn2s @janl

Even if it was restricted to your home timeline (i.e. only messages that were sent to you more-or-less explicitly, either due to you being mentioned or due to you being in the followers of the author)?

@mcc @zarfeblong

It's interesting to see which of these additional features would need to be features of Mastodon(/Pleroma/Akkoma/Honk/...) and which would necessarily need to be features of ActivityPub (or are impossible for any protocol of the same shape).

In particular, "block all followers of X for the next week" is trivially defeated by X making their followers list private. However, one could do something like "block all people who have mentioned X in their publicly-readable posts within last N days for a week". This is obviously a heuristic that relies on those actually being public, so relies a bit on secrecy. I'd really like to see exploration of what can (and what cannot) be done that doesn't rely on secrecy of mechanism.

@wndlb @jonahstein @mart_brooks @mattblaze

IIUC you mean contracts that are take-it-or-leave-it and not subject to negotiation. They are restricted in using some clauses, but how can you have a shop that doesn't haggle without them?

@PennyOaken @TJ @vodamark @taylorlorenz

> 2: needed a central technological access control system to enforce it.

Not really. We already can kinda have it in some way:
a) the canonical view of the thread is served by your instance, so it can refuse to publish some replies there (using whatever internal logic it wishes to use),
b) when a reply is sent to the OP's followers, if the OP's followers list is not public, it's the OP's instance that does that forwarding (and can choose to refuse to do so based on any internal logic it uses).

If OP's instance is Mastodon/Pleroma/Akkoma and blocks (suspends) the domain of the replier, both of these things will happen. I don't know which kinds of other blocks (incl. in other instance software) will currently cause which subset of them to happen, but would hope that OP blocking the replier would also cause both to happen.

This obviously doesn't prevent the replier from sending that message to e.g. people explicitly mentioned. Alas, they could send such a message as a straight-up new message instead of a reply, and no reply-blocking would help with that (point (a) above already deals with visibility of that as a reply when viewing the OP's post).

@Leehro Well, if you plugged in something that blasted appropriate frequency noise over the power lines it wouldn't be weird that it could interfere with ~anything in the car (for large enough amplitude of the noise). Alas, it's not what you plugged in, so I'd have similar response to that happening as a result of plugging in a standards-conformant USB device

@Leehro If I were you, I'd try to figure out what's the layout of your car's CAN bus(es). First, the interesting question is whether there is a bus that's shared by anything related to motion and the entertainment stuff. Then, if (a) that bus is exposed in the OBD plug and (b) this sometimes reappears, you can attack a CAN bus sniffer there and see what kind of nonsense happens then (CAN does have a very reasonable notion of priotity, so I'd wager that the nonsense manifests as corrupt messages due to ~electrical interference).

I can't think of any connection that wouldn't be either via CAN or wouldn't be just power between the two, and I'd be _very_ surprised if that was mediated by power, so if it's not that I'd be (even more) surprised.

@foone

Do you know whether the key actually is intended to cause the lock to be unlocked? (Maybe the key was doing something wackier, while the solenoid was to declare the drive as safe for removal as @jhoward hypothesized.)

@rysiek

I'm not sure that a world where everyone solemnly sworn not to solve this problem wouldn't be better.

There are some (slow and costly) mechanisms that already provide some feedback: people move between instances depending on their instances' choices. The slowness and cost seems to be an obvious disadvantage, but it forces sparing usage. An advantage of these mechanisms is that proxies it uses are rather good.

Anything that involves measurement of faster effects involves creating proxies and acting on them. There is the obvious problem of optimizing for wrong proxies, but sadly there's also the problem of values of those proxies being touted publicly as reasons to choose your instance.

@rysiek

Introduction is also not really a single event here, which:
a) makes measuring effects harder, because introduction time is correlated with outcomes via the decision process that caused introduction to happen,
b) makes measuring effects harder, because effects might occur on the other end (out of "writer" and "reader") from where the change took place,
c) makes measuring effects easier if they are very fast (by looking at correlations in the time window where the introduction is happening).

(b) is a problem shared by experiments in anything-that-involves-person-to-person-interactions. (c) is sadly somewhat poorer than doing random assignment experiments on a single instance.

I wonder when we'll see first piece of instance software that (a) supports local experiments (or slow rollouts of features) that randomly assign users (b) supports multi-instance experiments. I'm not sure whether/in what form (b) would be a positive development though~~

@HerMamma @OscarBeau@mastodon.social @ADDiane

> So, what other ‘stone’ do you think killed more birds?

Earth. All the birds that die are killed by something on Earth (incl. disease, and arguably including ones that die of old age -- they would survive longer in a different environment).

@retr0id Then how does this differ from having a bunch of reed switches underneath that detect the status of the keys? (I'm probably missing some obvious part of the description.)

@retr0id Aah, you want to power the keys from a nontrivial distance?

@retr0id I'm confused. I expected that you wanted to power something in the part of the key that moves. But you don't need any powered part of the switch there: if nothing else, you can have a reed switch/Hall sensor under it and a magnet inside.

@retr0id What is powered in the key? (a light/a display/...?)

@niconiconi Do you know if people experimented with different symbolsets that could admit more density?

Why do PKP IC (https://www.pkp.pl/) and Blik (https://blik.com/en) put people under time pressure when performing transactions? They teach people to click stuff without reading (and probably also lose some part of ability to claim that customers really know the terms of service, given that they make them impossible to read in the timeframe).

@danluu Do you see a trend in frequency of such problems over time? (I know it can be hard to estimate that, given that company size often changes over time.) I'm curious to see if me seeing problems that are vaguely similar more is due to the world changing, or me getting to see a different part of it.

@cstross @garius

Showers that are combined with a tap even already have a valve fit for the purpose.