Assuming a mechanism exists that changes the universe from being singly connected to multiply connected (i.e., wormholes exist), it is possible to have wormholes permitting faster-than-light travel without time paradoxes, though some additional restrictions may apply.

We have already shown that wormholes connect across both space and time, so that a trip between star systems could take you hundreds of years into the future, and the return trip takes you hundreds of years back in time. And this is even before we throw in how time slips between planets when considering relativistic time dilation due to different speeds and gravitational potentials.

Fortunately, all the weirdness of different time rates and going backward and forward in time can be ignored by the average person. This is because you never need to go from one world to another, or back, across the vast gulfs of interstellar space. You just take the wormhole between them. All you ever need to worry about is the coordinate frame that goes across the wormhole. When considering this reference frame, you’re not hopping all over the place in time. If it takes ten minutes to cross the wormhole between the two planets, when you get to your destination world the clocks will read ten minutes later than they did when you left your departure world. By coordinating their time-keeping across the wormhole network, all of the worlds of the network can agree on a common time to coordinate their activities. This is all travelers ever need to worry about, and they can then ignore all the relativistic weirdness. Your network engineers will still need to keep track of relative time drift and how close a given configuration is getting to a time loop. But unless your protagonist is a network engineer, they can just ignore all that stuff. And, as an author, so can you! Assume your engineers are competent, you have good regulatory bodies and standards institutions, and don’t worry about any of this “time travel” that doesn’t actually let you cause paradoxes.

source: Galactic Library

Yes, it is visible when a new trusted device is added. The QR code you scan to link a device contains a one-time public key for that device (ECC is used partly to fit the public key more easily into a QR code). Signal on the phone then sends a lot of information, including the identity keys, to the new device. The new device uses these identity keys to communicate. Note that the transfer of identity keys is fully encrypted, with encryption and decryption taking place on the clients. This can, of course, be bypassed if someone you’re talking to has their security key compromised, but the same risk exists if the recipient takes a screenshot or photographs their device’s screen.

Edit: The security key refers to the one-time key pair generated to initiate the transfer of identity keys and chat history. It can be compromised if someone accidentally scans a QR code and transfers their identity keys to an untrusted device.

I assumed that not only the entire app but also the entire client device had been audited. This was a client-side attack, not Meta momentarily adding itself to the trusted-device list. I’m confident it was a client-side attack because it would be impossible to hide even a momentary change in keys from the client without modifying the client app to conceal such a change.

Even in an “insecure” app without air-gapped systems or manual encryption, creating a backdoor to access plaintext messages is still very difficult if the app is well audited, open source, and encrypts messages with the recipient’s public key or a symmetric key before sending ciphertext to a third-party server.

If you trust the client-side implementation and the mathematics behind the symmetric and asymmetric algorithms, messages remains secure even if the centralized server is compromised. The client-side implementation can be verified by inspecting the source code if the app is open source and the device is trusted (for example, there is no ring-zero vulnerability).

The key exchange itself remains somewhat vulnerable if there is no other secure channel to verify that the correct public keys were exchanged. However, once the public keys have been correctly exchanged, the communication is secure.

There is no central location to donate to open source software in general. Most open source projects include donation details on their website or in their code repositories.

%20 is the URL-encoded form of a space; %25 is the URL-encoded form of the percent sign. The URL you are posting gets re-encoded and % becomes %25 (in the same way that a space becomes %20)

Could the app be using cell tower data to bypass mock location settings? The Github repository says it identifies a user’s location using cell tower data.

If I understand the model you proposed correctly, it basically consists of making a payment to someone (whether an instance or a central authority), obtaining tokens in exchange, giving tokens to a content creator, and the content creator exchanging them to get their money back.

Having a central authority wouldn’t work because it goes against the principles of the Fediverse and most users would prefer that there not be a single point of failure. Having an instance exchange money for tokens wouldn’t work because there is no scarcity of tokens and no guarantee that an instance honours a request.

This method could instead be replaced by content creators adding links to receive payments with people giving money to them directly.

The problem is that there is nothing meaningful you can exchange this currency for. The Fediverse is fundamentally designed to allow anyone to start a server. There is no meaningful way to reward someone with anything of value except the satisfaction of having helped grow the instance they are supporting. There is no good way to boost someone without manipulating the vote count or changing the protocol itself. Many apps already offer customizability while simultaneously being free as in free beer and free as in free speech. The main reason many people move to the Fediverse is to escape an internet where everything is “enshittified,” and most Fediverse users wouldn’t want to shift to a proprietary model.

Not all hierarchies are bad. For instance, in a judicial system, there need to be different tiers of courts as otherwise, if courts had universal authority and made conflicting decisions, it would complicate the law more so than it is already.

Similarly, in a large society that needs unity, if people make all decisions, the results would be catastrophic as most people don’t have the time or energy to focus on every mundane decision. In such a case, elected representatives becomes mandatory, creating a hierarchy.

Yet another example is cases where fast decision-making is required (e.g., to respond to an emergency). In such a case, there needs to be a central authority who holds others responsible and coordinates response.

Ultimately, if you consider a hierarchy where accountability is possible i.e. one party may have more power over the second than the second over first but the second still has some power over the first, then it makes accountability possible in hierarchies. Hierarchies are only wrong when the power gap increases, a small power gap is alright provided it doesn’t widen with time.

You could make the argument that a chain of accountability is better (X->Y->Z->X), but even such chains may include hierarchies (i.e. X itself is a hierarchy). Similarly, authority diffused among different people also suffers from potential shifting of blame. Truly neutral relations between different parties are impossible and ultimately, a power difference exists between any two parties, though it may be minute, and this power gap must be acknowledged.

In conclusion, there are a lot of disadvantages of hierarchies but there are some domains where hierarchies are good. There is no system of distribution of power that is without flaws.

ASCII was interpreted as UTF because the function that checked whether the given text was Unicode checked the difference between bytes at even and odd positions. Many of the common phrases used to trigger this were in the 4-3-3-5 format (by letters), e.g., Bush hid the facts However, there was never any reason that this format of character placement was necessary for the bug (though even length was necessary)