I do things somewhat similarly but still rely on Helm/customize/ArgoCD as it's what I know best. I don't have a documentation to offer, but I do have all of it publicly at https://gitlab.com/lama-corp/infra/infrastructure
It's probably a bit more involved than your OP's setup as I operate my own AS, but hopefully you'll find some interesting things in there.
Those guys are also opening "ad" issues on unrelated repositories[0]. Adding that to what others mentioned, it really doesn't inspire confidence in the software
When I saw that link I thought maybe it was one of those: "add X to the recommended libraries list" PRs or something like that. But this is wild... it's literally an advertisement.
The HA maintainers also refuse anything that has to do with SSO. I'm not even talking about implementing it themselves, there have been many contributions over the years to add OAuth support
So they made bad architecture decisions, blamed it on Kubernetes for some reason, and then decided to rebuild everything from scratch. Solid. The takeaway being what? Don't make bad decisions?
I've always been fond of blaming myself and asking everybody else to help make sure I don't cock it up a second time - when it works out I get lots of help, lots of useful feedback, and everybody else feels good about putting the effort in.
This does require management who won't punish you for recording it as your fault, though. I've been fairly lucky in that regard.
If you use powershell, what's your reaction when you delete some stuff by using the "-Force" parameter and that it's deleted ?
Steve usually said that Microsoft should ask for a confirmation before deleting anything, even with the "-Force" parameter.
It was Microsoft's fault when the whole test environment, that he spent two days setting up, was deleted with the "-Force" parameter. He said something along the lines of "Microsoft shouldn't let me do this".
I think the takeaway was Kubernetes did not work for their team. Kubernetes was probably not the root problem but it sounds like they simplified their infrastructure greatly by standardizing on a small set of technologies.
Kubernetes is not an easy to use technology and sometimes its documentation is lacking. My gut feeling is Kubernetes is great if you have team members who are willing to learn how to use it, and you have a LOT of different containers to run. It probably is not the best solution for small to medium sized teams because of its complexity and cost.
It highlights a classic management failure that I see again and again and again: Executing a project without identifying the prerequisite domain expertise and ensuring you have the right people.
You only really answer question 2 of your parent, and they obviously meant for someone operating a Matrix server with regards to their users. It's pretty well summarized in Patrick Breyer's sumary page[0]:
> Only non-commercial services that are not ad-funded, such as many open source software, are out of scope
> How do you even ensure a client is actually self-reporting?
This is an interesting technical question whether or not it's covered by the actual proposal. How do you ensure that Messenger for instance is
1. actually doing the reporting, and not someone simply bypassing the app to keep sending e2ee chats without them being client-side scanned. That would most likely be against ToS and accounts would maybe get banned if doing so
2. prevent against spam reporting, where someone could basically DoS the reporting service with false positives
> If a photo are flagged, will it appear in a GDPR access request?
There are a bunch of dispositions in the draft concerning personal data protection (ctrl+f personal data to find the relevant articles). It also states pretty much everywhere that processing should be done in accordance with Regulation (EU) 2016/679, more commonly known as GDPR.
> Having regard to the availability of technologies that can be used to meet the
requirements of this Regulation whilst still allowing for end-to-end encryption, nothing in this Regulation should be interpreted as prohibiting, requiring to disable, or making end-to-end encryption impossible. Providers should remain free to offer services using end-to-end encryption and should not be obliged by this Regulation to decrypt data or create access to end-to-end encrypted data
I believe this was added as a request from France, which didn't want E2EE to be undermined by this proposal. However, the provider would need to "create access to end-to-end encrypted data" to report it to the EU Centre. Although the following article states that E2EE can still be used if you don't send images, videos and URLs, so I guess that's the compromise?
> Sorry, I don't follow. Am I misreading something? To me the the quoted text says the opposite.
Yeah me too. But how would the provider report CSAM content if they are not obliged to break encryption? I don't really follow the Regulation on that part.
It's a broad framework and - based on my cursory reading:
- providers have to set up a counter-abuse team and fund it
- authorities and industry-wide cooperation on trying to come up with guidelines and tech
- counter-abuse team needs to interpret the guidelines, do "due diligence"
- provider needs to have monitoring to at least have an idea of abuse risks
- if there are, work on addressing them if possible without breaking privacy
As far as I understand the point is have more of services like "YouTube for Kids", where you can give your kid an account and they can only see stuff tagged "kid appropriate" (and YT simply said we are going to be sure there are no bad comments, so there's no comment section for these videos - which hurts their engagement, which hurts profitability).
There's a section about penalties and fines, up to 6% of global revenue, if the provider doesn't take abuse seriously. And - again, based on my understanding - this is exactly to prod big services to make these "safer, but less profitable" options.
Call your representatives and try to get into contact with the key civil servants involved. Then explain the problem to them. Just an honest argument. I mean a lot of us have kids and want to protect them. Totally agree with the concept.
Only this isn't something which can be solved by technical measures without abandoning "Liberté, égalité, fraternité". This is something for China/Russia/Iran/North Korea/England, not France.
This looks so much better than everything out there.
Only thing that irritates me is sso being locked behind a paid offering. No one should be required to pay for proper security when you offer a free option.
It's annoying that SSO is behind a paid offering, but it is mostly a convenience feature and you don't need it "for proper security"; so I can understand it being used as a way to monetize an open-source product.
reply