

Planners do a lot of preparatory work before laying cables, but based on the few articles and studies I could find online, it appears they rarely share their findings with the public.


Planners do a lot of preparatory work before laying cables, but based on the few articles and studies I could find online, it appears they rarely share their findings with the public.


Sabotage can also be carried out without submarines. For example, a ship could drag its anchor along the seabed (whether in the Baltic Sea or the Taiwan Strait) near known locations of internet cables.


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.


Enable Administrator password on the menu screen, create a persistent storage (if it doesn’t already exist), download the Flatpak file from the website, and run
torify flatpak install /path/to/file
flatpak run io.github.softfever.OrcaSlicer
Using an AppImage is not a good idea because they have a tendency to give errors if proper software and version are not installed on Tails (on my Tails USB, this was because of GCC) unless you compile your own AppImage. Using Flatpak is better as it allows you to run software on your system even if the versions of GCC etc. are not up to date.
Please keep in mind that I have not confirmed whether this method is secure and would advise that you consider whether this is secure or not depending on your threat model.


The DKTB is a personal app. It is therefore assumed, that the User will not share it with other people, and that only the User can access and control their personal DKTB. Ultimately, this means that all attestations in a DKTB are expected to pertain to and only be presented by the same User. This is enforced by requiring the user to authenticate using biometry or PIN-code when using the app and only allowing the DKTB application to be installed on one device per user. (from the PDF)
This is a false assumption: PIN codes can be bypassed by sharing them with others. Devices can be faked unless using hardware attestation, which prohibits any modifications to the device which may be undertaken by those interested in rooting or installing a custom OS.
Users can initially acquire a DKTB on their smartphone or tablet via Google Play or the Apple App store. (from the PDF)
This method requires the use of a vanilla, unmodified device, effectively prohibiting modifications to devices that one might wish to alter.
The URL you shared recommends using 99% IPA for electronics.