

Yeah I’m good thanks I’d rather use kanidm as SSO Server. It’s also opensource and made by people who know what they are doing.


Yeah I’m good thanks I’d rather use kanidm as SSO Server. It’s also opensource and made by people who know what they are doing.


Signal dies something called sealed Sender. The idea is, the sender information is encrypted in the package. https://signal.org/blog/sealed-sender/


Well, unless you login and transfer all your keys every time, the client already has all the info required to fetch and decrypt all the messages.


I know that you can configure synapse to delete messages. However every federated server only operates on their own delete scedule and you as the reciever can’t see the messages then anymore. Which I think is stupid.
The messages should only be stored on the reciever device after they were delivered and deleted on the transfering server.


I think a messaging server should store messages only until they are delivered. It shouldn’t have access to who sent it, only where they are going.
Matrix keeps a massive stack of metadata on the server, because the server takes care of the protocol and it needs all that metadata.
However you can’t loose data you never aggregated.


How do you migrate everything?


The way you currently say it, they tried to stop the exemption. They fought for the law, so OS gets an exemption.
Or do I understand you wrong?
We’ve got my 95 old grandma https://enna.care/ and she can use it. Instead of having to use the touch interface it works by placing cards on to an NFC reader.


What did you do about authentik always loading several seconds before login someone into a service?
Well, it startend with conduit. That was a respectable name. The development slowed down and someone wasnt happy abput not getting pr merged. Then it got forked to conduwuit.
Speed picked back up. There was later a massive meltdown for some reason. To successors emerged continuwuity and tuwunel.


Oh I missed that. Oh no. Rolling your own crypto, surely nothing can go wrong.


For a discord or Telegramm alternative it doesnt need to be e2e.


It’s also a lot harder to make money with open source. You would need to find something to offer on top for money. That can be hosting (nextcloud), support (redhat), consultation (hyper) or additional features(zeds AI offering).


In a side node: when building for geentoo it should be possible to build all rust libs as dylib. The compiler only offers a stable abi for the same version and all flags being equal. When building everything yourself that should work at the coat of updating the compiler requiring a complete rebuild of all libs.
Didnt know abput that.
They store where to deliver the message, but not from who that message came.


I should have been more clear.
I meant for self hosting.
Though realistically, even if the service is provided for the public, you could just use an instance of keycloak or something similar with open registration. That’s what an association I’m close to is doing already.


By default, the Credentials provider does not persist data in the database. However, you can still create and save any data in your database, you just have to provide the necessary logic, eg. to encrypt passwords, add rate-limiting, add password reset functionality, etc.
That is exactly the complexity I wouldn’t want. With just SSO it is enough to send a redirect URL to the browser and on the callback set a cookie. No js needed. If your service gets compromised and someone leeks the credentials, just log everyone out.


If i created a service I would go in the opposit direction. Only offer SSO and no other option.
You loose quite a bit of complexity that way.
Imagine, you run a 2 year attack in a package to compromise the ssh server indirectly, while you could have just send 257 A to the server.