Jump to content

Wikipedia:Reference desk/Archives/Computing/2021 April 3

From Wikipedia, the free encyclopedia
Computing desk
< April 2 << Mar | April | May >> Current desk >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


April 3[edit]

Matrix protocol, reliability and decentralization[edit]

If the Matrix (protocol) is 'decentralized', how can they guarantee that users can be differentiated? That is, no one can create a Bumptump user here in Wikipedia, because it's already taken by me, and the central server knows that. But how does the Matrix ecosystem deal with this? Do they have to check with some central server if user Abc is user Abc? In the same way we check with a DNS the IP of a site. Or does all messages have to go through the central servers? If it's the latter, wouldn't 'not a closed platform' be a better term instead of 'decentralized'? --Bumptump (talk) 02:41, 3 April 2021 (UTC)[reply]

It is not really logically different from how email works. Users are identified by a combination of an account name local to their service and an identifier for their service. For email, compare john316@gospel.org and john316@nasa.gov, which may be addresses of accounts of entirely unrelated users. Each service has their own user ID namespace over which it has exclusive control. Alternatively, users can be identified with a Matrix user ID, maintained centrally by the Matrix organization. Users can link their third-party IDs to their Matrix ID, and services can use a globally federated cluster of "identity servers" for mapping a Matrix user ID to a third-party ID.[1]  --Lambiam 10:40, 4 April 2021 (UTC)[reply]

Computer-generated animation of a person?[edit]

In this video (after the ad), this is a computer-generated animation of the woman speaking, right? If so, why is this done? Bubba73 You talkin' to me? 03:21, 3 April 2021 (UTC)[reply]

@Bubba73: It looks like a real person to me, based on the fact that there are multiple holes around them which would probably be the fault of the green screening/virtual background software. ―sportzpikachu my talkcontribs 03:30, 3 April 2021 (UTC)[reply]
I've seen her on TV many times, but this and what I saw yesterday don't look like the real person. Bubba73 You talkin' to me? 03:32, 3 April 2021 (UTC)[reply]

Compare it to the real person here. Bubba73 You talkin' to me? 03:37, 3 April 2021 (UTC)[reply]

The first video looks weird because it's staged in an unnatural way and the chroma key was not perfectly done, but I didn't see anything that made me think it was not a real person. Matt Deres (talk) 13:15, 3 April 2021 (UTC)[reply]
Well, at least it looks like a great deal of processing was done to smooth out her hair and skin texture. Bubba73 You talkin' to me? 00:23, 4 April 2021 (UTC)[reply]
Another video for comparison.  --Lambiam 00:22, 4 April 2021 (UTC)[reply]
That one also doesn't look natural. Bubba73 You talkin' to me? 00:25, 4 April 2021 (UTC)[reply]
No wrinkles and skin spots are visible, unlike in most photographs, like this headshot. This may be due to a generous application of foundation combined with illumination by diffused light. Early CGI did not simulate the natural unevenness of human skin, so the absence in the video may come across as CGI. Today’s better deepfakes look just as natural to the eye as the real thing, so if we are watching a simulacrum, it is because the Conspiracy are a bunch of cheapskates.  --Lambiam 10:11, 4 April 2021 (UTC)[reply]
In that headshot, you can see individual hairs. But in the two videos that don't look natural to me, the hair is just a dark mass. Also, I've seen a few videos of Mrs. Betty Bowers that look the same. Bubba73 You talkin' to me? 03:09, 5 April 2021 (UTC)[reply]
Video is compressed. Depending on the level of compression and the method used, similar colors (which are necessary to see individual hairs) are compressed into one single-color blob. If you compress it enough, she would look like she came out of an 80's video game with 8-bit color. Does that mean that it is all fake and there is a big consipiracy? No. Not in the least. If there was a conspiracy, she would be part of it and they would use her in the videos, just like they did when those same people faked the Moon landing. 97.82.165.112 (talk) 19:27, 7 April 2021 (UTC)[reply]
Besides compression and resolution, it also depends on the colour balance etc, since her hair seems fairly dark. Consider this Getty image [2]. If you zoom in you can see some strands of hair but at least for me at normal size you can't see any that well. Nil Einne (talk) 07:48, 8 April 2021 (UTC)[reply]

The problem of primary key assigning[edit]

I remember that once I've read, that assigning primary key may be problematic:

  1. You might not want it to be based on a simple series, as an attacker can estimate the number of users in the system.
  2. You want it be relatively short, otherwise the index might increase in size.
  3. There are of course other consideration, if more than one server writes in parallel rows, which might have conflicts.

What is the name of the field in Computer science that deals with that? --Exx8 (talk) 11:35, 3 April 2021 (UTC)[reply]

In most uses of primary keys there is no relation to the number of records in a database table and the number of users of a system. Assuming keys consisting of a single field, generated as records are added, I think that one should not have much concern about the size of the index, for example when using a hash table. (See Database index § Index implementations.) When using a hash table, one approach that is possible when primary keys need to be externally visible, is the following. When a new primary key has to be generated, have the software create, say, a random eight-digit sequence with an additional check digit, and compute its hash. If already in use, it should repeat until a unique hash is obtained. This has the advantage that the hash table implementation does not have to address the issue of hash collisions, and that the hash size can be kept sweet and short.  --Lambiam 00:09, 4 April 2021 (UTC)[reply]
This suggestion however creates a different problem, the id which are assigned are not dense. Meaning that most of the addresses will never be used. Though in some cases it is irrelevant for some cases (like assigning person IDs for example) this might not be enough. furthermore, it is not deterministic, therefore, theoretically in wc, it might not end.--Exx8 (talk) 12:59, 5 April 2021 (UTC)[reply]
If you need consecutive keys, a possibility is to encrypt them with a block cypher with a small block size, such as Blowfish, which has a 64-bit block size. There is currently no known-plaintext attack on Blowfish, so there should be no obvious correlation between the ciphertexts of very similar plaintexts. A 64-bit block of ciphertext can be represented in human-processible form in a string of 13 alphanumeric characters, also if the letter "O" is excluded. (You can even also exclude "I", "Z" and "S", which might be misread as "1", "2" and "5".)  --Lambiam 10:12, 6 April 2021 (UTC)[reply]
  • What is your actual use case? There are lots of properties one might want or not want and many of them are incompatible. There is no one-size-fits-all key generation scheme.
For instance, you seem to be asking that the key generation (1) is thread-safe (point #3), (2) uses a small key length compared to the space of possibilities, and (3) key generation is guaranteed to terminate in constant time (not just almost surely) (your reply to Lambiam). I am pretty sure all three cannot be met simultaneously. TigraanClick here to contact me 10:35, 7 April 2021 (UTC)[reply]
actually I believe I did invent an algorithm that does terminate in O(log (n) ) time which is not constant, but still poses the 3 properties (beside the constant time part).--Exx8 (talk) 20:58, 7 April 2021 (UTC)[reply]