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.
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)?
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.
quote-toot meta, measuring effect
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.
quote-toot meta, measuring effect
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~~
@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.
I enjoy things around information theory (and data compression), complexity theory (and cryptography), read hard scifi, currently work on weird ML (we'll see how it goes), am somewhat literal minded and have approximate knowledge of random things. I like when statements have truth values, and when things can be described simply (which is not exactly the same as shortly) and yet have interesting properties.
I live in the largest city of Switzerland (and yet have cow and sheep pastures and a swimmable lake within a few hundred meters of my place :)). I speak Polish, English, German, and can understand simple Swiss German and French.
If in doubt, please err on the side of being direct with me. I very much appreciate when people tell me that I'm being inaccurate. I think that satisfying people's curiosity is the most important thing I could be doing (and usually enjoy doing it). I am normally terse in my writing and would appreciate requests to verbosify.
I appreciate it if my grammar or style is corrected (in any of the languages I use here).