I think I have also seen socket access in Nginx Proxy Manager in some example now. I don’t really know the advantages other than that you are able to use the container names for your proxy hosts instead of IP and port
I don’t think you need socket access for this? This is what I did: https://stackoverflow.com/questions/31149501/how-to-reach-docker-containers-by-name-instead-of-ip-address#35691865
I’ve seen three cases where the docker socket gets exposed to the container (perhaps there are more but I haven’t seen any?):
Watchtower, which does auto updates and/or notifies people
Nextcloud AIO, which uses a management container that controls the docker socket to deploy the rest of the stuff nextcloud wants.
Traefik, which reads the docker socket to automatically reverse proxy services.
Nextcloud does the AIO, because Nextcloud is a complex service, but it grows to be very complex if you want more features or performance. The AIO handles deploying all the tertiary services for you, but something like this is how you would do it yourself: https://github.com/pimylifeup/compose/blob/main/nextcloud/signed/compose.yaml . Also, that example docker compose does not include other services, like collabara office, which is the google docs/sheets/slides alternative, a web based office.
Compare this to the kubernetes deployment, which yes, may look intimidating at first. But actually, many of the complexities that the docker deploy of nextcloud has are automated away. Enabling the Collabara office is just collabara.enabled: true in the configuration of it. Tertiary services like Redis or the database, are included in the Kubernetes package as well. Instead of configuring the containers itself, it lets you configure the database parameters via yaml, and other nice things.
For case 3, Kubernetes has a feature called an “Ingress”, which is essentially a standardized configuration for a reverse proxy that you can either separate out, or one is provided as part of the packages. For example, the nextcloud kubernetes package I linked above, has a way to handle ingresses in the config.
Kubernetes handles these things pretty well, and it’s part of why I switched. I do auto upgrade, but I only auto upgrade my services, within the supported stable release, which is compatible for auto upgrades and won’t break anything. This enables me to get automatic security updates for a period of time, before having to do a manual and potentially breaking upgrade.
TLDR: You are asking questions that Kubernetes has answers to.
Try the yaml language server by red hat, it comes with a docker compose validator.
But in general, off the top of my head, dashes = list. No dashes is a dictionary.
So this is a list:
thing:
- 1
- 2
And this is a dictionary:
dict:
key1: value1
key2: value2
And then when they can be combined into a list of dictionaries.
listofdicts:
- key1dict1: value1dict1
- key1dict2: value1dict2
key2dict2: value2dict2
And then abother thing to note is that yaml wilL convert things into a string. So if you have ports 8080:80, this will be converted into a string, which is a clue that this is a string in a list, rather than a dictionary.
Signal’s reproducible builds are broken: https://github.com/signalapp/Signal-Android/issues/13565
Many helm charts, like authentik or forgejo integrate bitnami helmcharts for their databases. So that’s why this is concerning to me,
But, I was planning to switch to operators like cloudnativepostgres for my databases instead and disable the builtin bitnami images. When using the builtin bitnami images, automatic migration between major releases is not supported, you have to do it yourself manually and that dissapointed me.
So Signal does not have reproducible builds, which are very concerning securitywise. I talk about it in this comment: https://programming.dev/post/33557941/18030327 . The TLDR is that no reproducible builds = impossible to detect if you are getting an unmodified version of the client.
Centralized servers compound these security issues and make it worse. If the client is vulnerable to some form of replacement attack, then they could use a much more subtle, difficult to detect backdoor, like a weaker crypto implementation, which leaks meta/userdata.
With decentralized/federated services, if a client is using other servers other than the “main” one, you either have to compromise both the client and the server, or compromise the client in a very obvious way that causes the client to send extra data to server’s it shouldn’t be sending data too.
A big part of the problem comes with what Github calls “bugdoors”. These are “accidental” bugs that are backdoors. With a centralized service, it becomes much easier to introduce “bugdoors” because all the data routes through one service, which could then silently take advantage of this bug on their own servers.
This is my concern with Signal being centralized. But mostly I’d say don’t worry about it, threat model and all that.
I’m just gonna @ everybody who was in the conversation. I posted this top level for visibility.
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected]
EDIT: elsewhere in the thread it is talked about what is probably a nation state wiretapping attempt on an XMPP service: https://www.devever.net/~hl/xmpp-incident
For a similar threat model, signal is simply not adequate for reasons I mentioned above, and that’s probably what poqVoq was referring to when he mentioned how it was discussed here.
The only timestamps shared are when they signed up and when they last connected. This is well established by court documents that Signal themselves share publicly.
This of course, assumes I trust the courts. But if I am seeking maximum privacy/security, I should not have to do that.
Maybe nginx proxy manager can do this.
I took a look through the twitter, which someone mentioned in another thread.
Given the 4chan like aestetic of your twitter post, I decided to take a look through the boards and it only took me less than a minute to find the n word being used.
Oh, and all the accounts are truly anonymous, rather than pseudoanonymous, which must make moderation a nightmare. Moderation being technically possible doesn’t make it easy or practical to do.
I don’t want an unmoderated experience by default, either.
No, I’m good. I think I’ll stay far away from plebbit.
To be pedantic, lemmy is federated, rather than decentralized (e.g. a direct p2p architecture).
With decentralization, moderation is much harder than federation, so many people aren’t a fan.
This isn’t exactly what you want. But I use a static site generator, with a fulltext search engine (that operates entirely locally!), called quarto. (although there are other options).
Although I call it a “blog”, it really is more of a personal data dump for me, where I put all my notes down and also record all my processes as I work through projects. Whenever I am redoing something I know I did in an old project, or something I saved here (but disguised as a blogpost), I can just search for it.
Here is my site: https://moonpiedumplings.github.io/ . You can try search at the top right (requires javascript).
Lol I misread it too.
There is literally no way to do performant e2ee at large scale. e2ee works by encrypting every message for every recipient, on the users device.
At 1000 users, that’s basically a public room.
There a source port of at least portal 1.
https://github.com/AruMoon/source-engine
Here’s the active fork of the original project. Going through the issues of the original project, it seems to have support for building for 64 bit platforms.
No portal 2 support though. Although mentioned in the issues of nileusr’s repo is this: https://github.com/EpicSentry/P2ASW , which is interesting
You should look into “Configuration as code”, where you use automation via various methods and store the code in a git repo. The other commenter in the thread is a good example of this methodology, using Terraform and Ansible, but there are many ways to do this.
I think the mistake is they titled it “The last note taking app you’ll ever need” instead of “The last note taking app I’lll ever need”
Yes, seriously. The article seems to talk mostly about their personal usecases, which is fine. This app is great and it works for them. But it won’t work for everybody and the title should probably respect that instead of having a grating title that evokes a knee jerk reaction.
Databases are annoying it is legitimately more difficult to export data from a database to another, than it is to copy markdown notes from one folder to another. In addition to that, there are also tools that process markdown and do cool stuff with, like pandoc, beamer, revealjs, etc, which can’t really be done with the more opaque database format.
Also this notetaking service only appears to work while online. Again, fine for them — but a dealbreaker for many people.
Alright, this is gonna be long.
Firstly, yes, different static site generators have different templating langauges. But just like normal programming languages, it is easy to transition from one templating langauge to another. If you take a look at the syntax:
Not drastically different, but reading the docs, they are all similar enough, and easy to learn.
I wouldn’t call go’s templating language “esoteric”, but it should be noted that jinja2 is has other uses, most notably it is the templating engine that Ansible uses.
As for the docs… This could probably be a blog post by itself.
Firstly, take a look at this website: https://killedbygoogle.com/ . Google has created and then killed 296 projects, many of which were actively used and working. Why?
This is because, internally at Google, you get promoted if you either A: write software, or B: add more features to software. So what happens is people write software, get promoted, and then realize they don’t get paid more if they actually maintain that software, so they just kill it. Also, they forget to write documentation (because it doesn’t pay more or get you promoted).
Hugo, is by a Google Engineer, and it shows (or at least, it used to). Software by Google has two distinct characteristics (actually 3 if we count being written in Go).
But, “being poorly documented” is not a permanent fixture of this software, but instead something that mostly persists for as long as it’s Google software. Often, these projects get “adopted” by the wider community, who fixes up their documentation. Looking at hugo’s docs, it doesn’t seem be nightmarishly bad, especially for the core, main set of features. Like the setup docs appear to be clear (although a more complex process than alternatives).
But like, for search options: https://gohugo.io/tools/search/ . That google software pattern continues. There are like 10 options on the page, and no docs from hugo on their usage/installation lol.
Anyway, I would recommend eithier Pelican or Jekyll, given your requirements. Because everything you write is in markdown, it will be fairly easy to move from one static site generator to another, even if you are dissatisfied.
Also, kinda sorta relevant:
(source)
But the point I’m trying to make is the same. Don’t agonize over selecting the perfect static site generator.
I already made a comment but you should also look at rocketchat and revolt, since they are basically FOSS discord clones
(I saw comments in the thread about wanting audio only calls.)
There are a few apps that I think fit this use case really well.
Languagetool is a spelling and grammer checker that has a server client model. Libreoffice now has built in languagetool integration, where it can acess a server of your choosing. I make it access the server I run locally, since archlinux packages languagetool.
Another is stirling-pdf. This is a really good pdf manipulation program that people like, that comes as a server with a web interface.