robryk @robryk@qoto.org

@techlife @lauren

I don't know what bitchain in; based on 30s on Google it seems to be Yet Another blockchain thingy. I will assume so below.

You might wish to take a look at namecoin, which is (was?) an attempt at doing DNS that way.

Note that blockchains don't magically solve consensus. They provide solutions under additional assumptions of a very weird shape (PoW ones' assumption is ~"no one can acquire as much as a third of the computational power we are burning", PoS ones' assumption is ~"no one can acquire a third of the tokens we are keeping track of ownership of").

@techlife @lauren

So, whatever you do, the duality from my original comment applies: you either need global consensus (in the meaning of https://en.wikipedia.org/wiki/Consensus_(computer_science)), or identifiers can't be freely chosen. (Otherwise you could impersonate a user by "just happening" to choose the identifier they are using. Preventing that is ~equivalent[1] to consensus.)

[1] "~" because I haven't thought enough to prove it

@techlife @lauren

You mean like the way tor finds and authenticates hidden services? The authn story there is also "hand the user a private key".

@techlife @lauren

> I guess I see something like tor network for authentication.

I don't understand how. Tor establishes short-lived circuits. There are (by intent!) no long-term identities anywhere.

You might with to take a look at Secure Scuttlebutt. It implements the "hand the user a private key" approach.

@annaleen

Is the situation with replies that get boosted markedly different?

@lauren @techlife

We still need to authenticate messages from the user. We can either have the handle be associated with a public key (and hand the user the private key), or with some sort of key trust system. In either case we need a mechanism that creates a trusted association of the handle with the key/... (imagine two users creating the same handle: how do we make it so that they don't impersonate one another?).

So, we need either handles that aren't chosen freely or global consensus.

Two obvious approaches, both with warts, are:
- handle _is_ the public key, private key is in user's hand (warts: loss of private key and its leak are both unfixable, handles are meaningless gobbledygook),
- hang handle->public key assignment off a global CA system: TLS CAs (warts: we require intermediaries who own domains and who are trusted to act as the user, we can't switch between intermediaries without lasting cooperation of the previous one).

Do you see other approaches/classes of approaches?

@Tiernan Do you mean https://pl.wikipedia.org/wiki/Placki_ziemniaczane#/media/Plik:Bramboracky.jpg?

@Magdalena

Was bedeutet "Behördennummer"?

@techlife @lauren

Small suggestion: if you chained your next reply as a reply to the _previous_ one, instead of as a reply to the original post, you'd make it easier to follow.

@lauren @techlife

There is the annoying conflation of (at least) two things that an instance is: identity provider and community. If we could decouple those at least somewhat, one could imagine a setup where one could be a member of many instances. In that world instance choice is much easier ("identity provider" is not important ~at all, "community" is postponeable).

@marqle @lauren

Apart from Lauren's point besides, delay might increase required effort to re-find all the people one was connected with (because lack of delay causes them to find you in some fraction of cases).

@filippo @Natanael_L @juliank

I wonder if there is a primitive that would allow us to protect inactive users (e.g. something like a "step" function that takes us from key_i to key_{i+1} that's sufficiently expensive etc. and a corresponding function that takes a ciphertext decryptable with key_i and makes a ciphertext decryptable with key_i+1 out of it without access to either).

@styfle @SwiftOnSecurity

They often don't display them, but have them on request. I think that in some areas that's a requirement (because the menu tells you about possible allergens in dishes).

@TindrasGrove @SwiftOnSecurity

Do you have a description of what exploded? (I'm surprised by explosions: _flow_ water heaters had failure modes of starting fires, but ~no way to create large enough pressure to explode. I'd rather expect fires and scalding.)

@SwiftOnSecurity

It's amusing what different sets of safety sensors are there in European and USAian furnaces.

In US, all such furnaces have a flame-out-of-bounds detector and often don't have a detector of chimney draft (or rather, detector of fume spillover from the chimney hood). In Europe, the exact opposite is the case normally. (TTBOMK these two sensors would usually both detect lack of smoke flow, because it causes the flame to get bent out of shape.)

@bert_hubert

This seems to suffer from the same problem that fast-math suffers from: you enable it for everyone, including all the libraries you use. Those might rely on the exact opposite state (as that's the default).

@bliss @woozle

We have lots of possible heuristics. For example, a simple heuristic is "federate with instances if they contain a user that's followed by someone followed by one of our users" (i.e. at distance of <=2 in directed graph of follows).

Also, making it costly (applying moderation actions per ~everything-under-same-domain-registration) might be sufficient.

@tedivm @woozle

I'm not sure if you know about https://en.wikipedia.org/wiki/Public_Suffix_List. You could use it to figure out at which level you might want to "agggregate responsibility".

@Cat_LeFey

Doesn't 3 conflict with 4 and 5? I wouldn't personally tell someone that I see e.g. a close-up of cable, but rather that I see a cable.

What do you think about including (factual) information that does not exist in the image (e.g. that this is a still from movie X, or that this PCB is actually a power supply from device Y)?