

Wann ist Sylt nochmal dran, beim steigenden Meeresspiegel unterzugehen?
Die sind eh früh eingeplant, wenn mich nicht alles täuscht.
[Verifying my OpenPGP key: openpgp4fpr:FED82F1C73FF53FB1EE9926336615E0FD12833CF]
Wann ist Sylt nochmal dran, beim steigenden Meeresspiegel unterzugehen?
Die sind eh früh eingeplant, wenn mich nicht alles täuscht.
Geh bitte…
Was genau “erschlägt” einen bei friendica?
Du hast ein “network”, deine Kontakte. Eine lokale und globale community Deine eigrnen Postings.
Das hast du bei Mastodon auch.
Du hast eine Suche, deine Kontakte und mehr brauchst du am Anfang nicht.
Und jetzt postings formatieren… das ist nicht schlimm… das kennt man von unzähligen Anwendungen genau so.
Kalender… ist eh versteckt. Der erschlägt nicht, den muss man sogar suchen.
Verschiedene Identitäten erschlagen nicht, die muss man auch suchen…
Aber nach 500 Ueichen NICHT hingewiesen zu werden, dass das Posting zu lange ist… oder bei mehreren Bildern, dass diese zuviel sind… das stört nicht, sonder behindert nicht künstlich den Schreibfluss.
Würdest du recht haben, hätte sich Facebook nie so durchsetzen können, wie es tat…
Wenn du meinst.
Geh bitte… das ist doch FUD.
Was spricht gegen die Webapp? Was spricht dagegen, Friendica im Browser zu öffnen und dann als PWA zu “installieren”?
Was heißt, es “kann zuviel”?
Ein Posting verfassen, Liken, Sharen, ein Bild anhängen schafft jeder Depp. Wer Mastodon bedienrn kann, kann auch Friendica bedienen.
Und wer wirklich eine App braucht… nimmt eine für Mastodon und gut ists. Friendica unterstützt auch die Mastofon-API und ist daher nahezu vollständig kompatibel mit Masto-Apps…
Fedilab, z.B. funktioniert ausgezeichnet mit Friendica.
Aber zu behaupten, dass Friendica keine Apps hat und “zu kompliziert” sei, ist Unfug.
Ich weiß, dass ich oft damit nerve… aber ich möchte auch den Focus durchaus auf Friendica lenken…
Friendica ist ein sehr feature-reicher Fediverse-Service.
Soweit ich das bis jetzt mitbekommen habe einer der ganz wenigen (neben den Friendica-Abkömmlingen wie Hubzilla oder eben Lemmy), die eine ordentliche Threaddarstellung können.
Gerade wenn es um Diskussionen oder Austausch geht (und darum gehts doch bei Social Media…) ist friendica super. Keine Zeichenbeschränkung, daher auch kein Gestottere in 500-Zeichen-Häppchen, die Möglichkeit Bilder in den Text an richtiger Stelle einzubauen, und deren mehr als 4, verschiedenste Zextauszeichnungen (Überschriften, Hervorhebungen, Quotes, Code, Aufzählungen,…) und mit dem kommenden Release endlich auch einen modernen Bildupload per Drag&Drop und Copy&Paste, Kalender,Events, Gruppen, Foren, mehrere Identitäten mit einem Login, RSS-Feeds abonnieren, usw, usf.
Ich hab auch vieles probiert. Von Mastodon über Pleroma, Misskey, Hubzilla… gibt ja viel. Ich hab mir bis Misskey alles selbst gehostet. Kam aber immer wieder auf Friendica zurück. (Und Lemmy. Schreibe von meiner eigenen Instanz).
Ich mag den Gedanken und die Umsetzung von FOSS und der Föderation. Ich denke und hoffe, DAS wird das Web 3.0. Und nicht der Meta-Käse oder der vollkommerzialisierte Online-Mist.
Der Gedanke vom Web 1.0 mit der Technik von heute… die Vervindung ist das Fediverse.
The services should be able, to talk to each other via ssh?
Or do you have groups of servers?
How many we are talking about?
They are all virtual servers?
Where is the hub located?
In our company we have many services and many servers. We are talking about hundrets of services and servers. Snd they are very secure.
So we have the servers on a big esxi (more than one) in 3 datacenters.
There is one jumphost (high available… several instances). Direct connection from our workstations to a server is not possible. We have to use this jumphost. Login on the jumphost is not possible, only for jumping (ssh option -J).
On the jumphost is for each user the publickey from a hardwaretoken. (Yubikey, etoken, nitrokey, name it) on its user in authorized-keys file. Only one pubkey.
So you are not able to jump over the jumphost to a server, without a valid hardwaretoken.
A NAT-Rule gives each user a individual source-IP…
Then you can see in auditlog on each server who did the shit… even if he made sudo su… the source-ip is individualized for each user.
And services run in different subnets and VLAN without connection to each other. So only services can talk together, who must talk.
Another server is an ansible machine. This can connect to every single server too and fo good and really bad things… so this ansible-machine and the jumphost are in a physically secured zone in the Datacenter.
You need an extra permission and an extra physical key, to come to this machines…
And if one Service gets compromized, maximum the servers in the same vlan or subnet can be affected too. And the servers, which got an extra firewall-hole.
So… if you are afraid of using ssh in your environment…
Use hardware-keys for the ssh privatekey. No softwarekeys! If machines need to talk together via ssh, make smallest possible jails with subnets or vlans around them. Think about allowed commands in ssh-config/authorized_keys file!!! Think about a jumphost and allow different users only machines which they need. Think about physically protection about the jumphost. Think about serverinitiated backups…
👍