gefhfff

No, it isn't a payment system.

Check out GNU Taler (and alternatives), which really are payment systems instead of currency alternatives

Which is externalizing the cost to the rest of society as there is either no or a too small carbon tax while the estimated cost on society varies between 700 Euros [0] and 100.000$ [1]

[0] https://www.umweltbundesamt.de/daten/umwelt-wirtschaft/gesel...

[1] https://link.springer.com/article/10.1007/s10584-020-02785-4

I think there are may be factors for Germany having high energy prices.

Correlation is not causation

Look at global prices: https://amp.dw.com/en/nuclear-climate-mycle-schneider-renewa...

Not true, it's too late for nuclear power. Additionally it is quite expensive compared to renewables and makes the burden on future generations even bigger.

Anyway, don't shut down any working plant early... We need everything we have atm

> MEGOLM seems to be encrypted group chat. OMEMO already provides that.

No, OMEMO is rather comparable to OLM. MEGOLM is a layer on top of that.

> Not sure what a session is or why it needs sync.

When you log in (on phone, browser, ...) you create a session

> XMPP is decentralized, maybe even more than Matrix,

Certainly not technology wise

> since almost everyone uses the official server matrix.org.

Less than a third

> It would be better to implement those features using existing Internet Standards

In your opinion. The success of Matrix today is enough for me to distance myself from purely idealistic views

> which takes us to the situation where Matrix has the exact same selling points which XMPP had 20 years ago... and keeps on reinventing the wheel

I don't get it. XMPP had MEGOLM, cross signing, decentralized chat rooms, good iOS support in practice, very simple sync of e2ee chat history, ... 20 years ago?

> spitting on other protocols (or not even acknowledging their existence) without a technical reasoning (Matrix could have been a "simple" decentralized room extension of XMPP or any other established protocol) ;

This simply so wrong: Matrix was created exactly because if the failure of existing protocols [0]. And the mentioned extension was one failure in their mind.

[0]: https://matrix.org/faq/#why-has-no-one-done-this-before%3F

And imho it was the best thing to do. You don't repair a car if repairing costs much more than getting a new one

> pushing for a broken state resolution algorithm (decentralized consensus) without a formal analysis, which means it's now reached its 5th or 6th version and Matrix

In fact there are 9 versions today. Though afaik only one of them was due to a broken consensus algorithm. Others exist for new features. Strangely I can use even the latest ones with alternative clients such as Fluffy Chat - contrary to your claims

> but why is a Jitsi <iframe> considered a decent extension mechanism

It is? Source needed

Native Matrix video chat is being implemented as of now

> putting all of their $$$$ into a single web client with very bad performance, not caring for other platforms

Also wrong: Element has a native Android and a native iOS clie t

Matrix has introduced some really neat innovations compared to XMPP:

- decentralized conversations instead of centralized ones

- MEGOLM

- Cross Signing

- monolithic protocol (i.e. one true way of doing things officially)

- easy sync of (encrypted) history between sessions

These are reasons why people use Matrix and not because of misinformation about how private it is

Also: afaik not everything applies to Matrix, e.g. a widely used server logging passwords or a server being able to manipulate chat rooms that extensively

Have you actually tried any alternatives at all?

Even Matrix with Element (which used to have quite a few issues with slowness and encryption), works way better these days

Not to mention any widely used centralized messenger...

Matrix has introduced some really neat innovations compared to XMPP:

- decentralized conversations instead of centralized ones

- MEGOLM

- Cross Signing

- monolithic protocol (i.e. one true way of doing things officially)

- easy sync of (encrypted) history between sessions

These are reasons why people use Matrix and not because of misinformation about how private it is

> who support ephemeral discussions and/or an explicit data retention policies

Matrix's variant of that: https://brendan.abolivier.bzh/matrix-retention-policies/

> In case that wasn't clear, in the XMPP model, the backlog for a room is kept on the room's server, not on every individual home server. In

Which makes your history dependent on a plethora of different servers. Result: very bad usability

> replicated on all servers

No, this is misleading. It is replicated between servers that have users participating in the conversation, i.e. know the conversation anyways

> which eats massive server resources

I'd like to have a source for that. To my knowledge Matrix cryptographically verifying actions between servers (prohibiting various bad actions due to the decentralized nature of rooms in Matrix) and the implied DAG is really what needs resources

Matrix

I would have commented that if you didn't

Interactive verification gets you access to all secrets too. It's a question of having enabled key backup without which you cloud loose keys

Matrix isn't centralized, though it's true servers do the heavy lifting for now (eventually you will be able to run the server on the clients)

Pardon regarding the audit.

But you don't have to verify each contact once, but each session the contact uses

Trouble in the sense that the most resource intensive room makes Synapse use about 700 mb of RAM

It's not. It doesn't work with iOS in practice and requires you to verify each single session instead of just a the people to prevent MITM attacks. Afaik it does not have any audit either

Multiple devices... without sync

Multiple platforms... but iOS a night mare with E2EE

Gateways to other networks... Honestly I couldn't find working ones

Why would you want to make a phone number your user ame - this way you are sharing it with almost everyone...

Can you explain that Tokio vs crossbeam vs rayon a bit more? Should I default to rayon or crossbeam because of that?

Well, generate the gas with renewables

It is not that bad... Compared to c

Throwing Rust into the pool

Element[0]: hast everything except probably push to talk.

You can freely choose a real server and can talk to anyone on any other server.

[0]: https://element.io

No nerdy guy pushes apple for security and privacy. It is all closed source with data leaking by default - partially not possible to turn off.

They rather push devices like librem 5, Pine phone, Fairphone with /e/os, but not Apple...

There are storage possibilities beyond batteries, e.g. hydrogen/methane

I don't see why they would complement themselves, and especially why you put Matrix into the slack/discord corner: Matrix is a protocol that is not designed to a specific use case.

Thanks for confirming

I think about types (almost?) every time I write a function. What type of data does the function expect, and what type of data am I supposed to transform this data to?

For instance, if I calculate the time that has elapsed between two points in time: - what does my input look like (e.g. two objects that look like XY) - in what form should I return the difference? Time in seconds (i.e. number), again an object that looks like XY ? ...

I can't imagine saying I would care about types rarely.

Another nice benefit of st langs is that you have to read manuals less often. IDEs so a way better job showing you the type of every variable (and result of an operation) as well as the options you have at your hand for a given type (including their documentation and example code). Yes I know dt languages and their tools try to catch up.

> or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug.

Well, I don't expect that with Dr languages as well, but I am glad that the compiler does this (or in DT languages at least the IDE due to type hints). I mean, it saves a lot of time (money) later on ... even if you notice it right away the first time you use the code

I can't answer your question. You may care since you may not want to break other code within the library that depends on what is returned by the function (depends how it looks like).

Otherwise I don't know why you would particularly care more about types with st than otherwise You'd just follow the same pattern as you did when extracting the other fields. E.g. if the fields to extract are listed in a list like structure, you're just going to add the extra field to the list. And in case of static typing, you'll get soonish feedback if you messed something up.

The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.