Begging crypto twitter to stop conflating the orders of a Canadian Provincial court based on well established legal procedures with potential impacts from Federal emergencies act invocation.
There is a lot to criticize and be concerned about, but conflation muddies the water.
I am very troubled by the invocation of the act - and more so with statements made by MPs to put forward legislation to make some of the powers relating to financial surveillance and/or censorship permanent.
While all extra-judicial freezing of assets is reprehensible I am very concerned with claims made in the house of commons this morning that Canadians who donated small amount of money are having their accounts frozen - if verified, those kinds of actions need intense scrutiny.
As it related to crypto I've seen 2 main things discussed:
1. A list of addresses provided by the rcmp to financial service providers under the emergencies order. 2. An order sent to a wallet software provider in reference to a mareva injunction via the Ontario Superior Court
The fact that the order asked a crypto wallet to do something that they simply can't do is certainly open to many critiques but it was the result of a well defined legal process - not an extra-judicial power grab.
For those not in Canada: we are in day 3 of a 4 all-day debate in parliament which will culminate with a vote on these orders. The act itself also has a built in sunset clause. There will be several inquires after, as I am sure there will be legislation and court cases.
Make no mistake that I am concerned and troubled - I've had parliament streaming all week.
But it is important to put developments in their proper context, so that when abuses of power happen they are clear, indisputable and can be properly challenged.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Deletion in p2p systems is weird because it violates many of the expectations that people have from centralized solutions.
e.g. If Alice purges all data about Bob as a contact, then the next time Bob attempts to connect to Alice it will be interpreted as a fresh request.
Alice is then left with 2 options: either add Bob as a contact again, or block Bob from all future conversations. Nether is great.
So "deletion" must mean something else to the app e.g. maybe we want to only display a new authentication request if Bob actually sends a message.
But that necessitates a "shadow record" or "placeholder" sitting in the storage engine that Alice might be unaware of if she has expectations other systems.
We can build UX to try and break those expectations, but "deletion" is then fundamentally the wrong word.
It's no secret that I have a hold "professional organizations" and "registries" as a whole in pretty low regard. One of the reasons I got into hacking in the first place was because it was one of the few paths where progress was not gate-kept by useless bureaucratic bullshit.
I'd be inclined to just argue along those lines if it wasn't for the fact that I am genuinely fearful of the authoritarian direction the UK has been heading down for the last 15 years or so - and what governments will do with the ridiculous amount of power they are accumulating.
In one future: identity is "verified" through intrusive facial analysis & state documents. Data is hosted, & trivially censored, by large conglomerates.
In another future: identities are bound through cryptography & data is distributed through uncensorable overlay networks.
There are laws being debated around the world right now that attempt to set the course for a future where human interaction is mediated through universal surveillance.
There is a very real choice to make regarding which future you want to contribute to, and build towards.
Through action, or inaction, you will contribute towards building one of these futures.
You have to ask yourself if the paths you are, or the decisions that your are making, are leading to a future that you want.
In @cwtch_im, file sharing is done via a torrent-like protocol where the file is chunked & each part can be requested individually (maybe from different people). Only the root hash is initially sent.
How should acks work?
A few caveats:
(2) Is currently implicit in the protocol as all messages are acknowledged
(3) might not always be possible right away (in group contexts) and so requires some extra effort on the recipients end.
Option (3) Also viscerally *feels* like a read receipt to me, even though it isn't necessary (we do allow auto downloading of images e.g.) - and so I think if we went that direction I would feel compelled to make it optional (but then it isn't an ack...)
As PoS is seen as inevitable for some cryptos there is an interesting meta shift away from "stop saying our consensus is centralized" towards "yes, the consensus is 'technically' centralized but *how* we arrive at consensus is less important than *what* we do with the consensus"
A few years ago i think I would have been under the impression that such rhetoric would effectively kill a community as they drop their committent to decentralization and concentrate power in a few hands.
lol
It feels like we are heading towards a point where there are the very few PoW currencies that have enough staying power to survive, and the rest of crypto will blend into a handful of very centralized payment processing hubs.
In a decentralized metadata resistant messenger where direct peer to peer messages may be unavailable because the other party is offline - what is the best way to order the conversation list:
(Note: Any solution to offline delivery likely carries an additional security assumption either in order to protect the metadata inherent to the conversation or in the risk involved in outsourcing storage)
This is actually slightly complicated by another factor: @cwtch_im doesn't save p2p conversation histories by default. It's a UX preference we adopted from Ricochet and does mean that "last message time" might be "Never" for some contacts even if you talk to them often.