KlyxIch habe mal den @martinmuc angeschrieben. Es muss doch ein paar Leute geben hier, welche die Instanz übernehmen und weiter betreiben würden. Also ich wäre dabei - aber nicht alleine, da bräuchte ich Hilfe an einigen Stellen. Wie seht ihr das? Vielleicht haben wir ne Möglichkeit, bevor alle umziehen müssen. Mitstreiter irgendwo? Gerne boosten! #TroetCafe #fedihelp #fragfedi
awlnx@klyx @martinmuc Nur als Frage, wäre eine Übernahme der Instanzen nicht ein riesiges Datenschutzproblem? Und jeder Nutzer müsste einzeln dem neuen Betreiber zustimmen?
@awlnx @martinmuc das ist eine sehr berechtigte Frage und wäre im Falle einer Übernahme zu klären. Aber meine erste Vermutung würde in genau die Richtung gehen. Welche Möglichkeiten es gibt, müsste man dann Datenschutz rechtlich prüfen.
@klyx @martinmuc Kam mir nur in den Sinn, weil auch Übernahmen von Mailinglisten und co oft an den rechtlichen Dingen scheitern :(. Weniger am technischen.
mʕ•ﻌ•ʔm bitPickup> weil auch Übernahmen von Mailinglisten und co oft an den rechtlichen Dingen scheitern
"Deutsche" .. echt, wer viel fragt wird wirr ..
BeiJoindiaspora damals, das wäre vergleichbar mit mastdodon.social (!) inklusive Kickstarter 250k USD crowdfunding hype, haben die damals ein bischen PM'ed und dann innerhalb der coder community das Ruder Übergeben, von den ursprünglichen diaspora* Erfinden in USA zu ein paar deutschen Codern.
Die Welt könnte so einfach sein.
@bitpickup @klyx @martinmuc Naja, rein rechtlich erwarten wir von Firmen dass sie bei Übernahmen etc gemäß GPDR arbeiten, so sollte man das bei einer so riesigen Nutzerbasis dann auch selbst handhaben.
@awlnx
mir reicht es wenn sie offen und ehrlich sind und offen und ehrlich kommunizieren damit mensch seine eigenen freien entscheidungen treffen kann.
ob @martinmuc, eine firma, ein politiker oder who ever.
"rein rechtlich" wird das umgesetzt was letzten endes dem stärkeren, dem system dem status quo dient. das war schon immer so und wird immer so bleiben.
wir sind hier in den freien dezentralen netzwerken. niemand wird gezwungen mit zu machen und jeder kann jeder zeit gehen.
das reicht.
@klyx
mir reicht es wenn sie offen und ehrlich sind und offen und ehrlich kommunizieren damit mensch seine eigenen freien entscheidungen treffen kann.
ob @martinmuc, eine firma, ein politiker oder who ever.
"rein rechtlich" wird das umgesetzt was letzten endes dem stärkeren, dem system dem status quo dient. das war schon immer so und wird immer so bleiben.
wir sind hier in den freien dezentralen netzwerken. niemand wird gezwungen mit zu machen und jeder kann jeder zeit gehen.
das reicht.
@klyx
@bitpickup @martinmuc @klyx Nach Gusto funktioniert Datenschutz aber nicht :). Wir reden hier auch von Daten in DMs etc, da ist das "du kannst jederzeit gehen" keine gute Einstellung.
Ein expliziter Opt-in wäre da wohl gefragt bei einem Betreiberwechsel.
@awlnx
> Ein expliziter Opt-in wäre wohl gefragt bei einem Betreiberwechsel.
Auf jeden Fall.
Offen und ehrlich zu kommunizieren impliziert das.
Natürlich reden wir von Daten, begrenzte tröt's und DM's. Ein idealer expliziter Opt-In wäre Passwortreset inklusive Email-Info und informativer Text auf spezifischer Passwortreset-Seite. Dort muss auch auf den Umstand hingewiesen und optionales downloaden/löschen des Profils ermöglicht werden.
@bitpickup @Gargron @martinmuc Idealerweise kommt die Aufforderung zur Löschung bevor die Daten transferiert wurden, aber yep genauso müsste es wohl laufen.
@awlnx
> bevor die Daten transferiert wurden
Sehe keinen Grund warum dies bei dem beschriebenen Vorgehen nicht funktionieren sollte:
* der alte "Provider" bzw unter den alten AGB wird der Passwortreset aktiviert, zusammen mit einem Ablaufdatum bzw in der Zukunft (1 Monat?) liegendem "Übergabedatum".
* alle Profile die bis dahin nicht eingewilligt haben werden gesperrt oder gelöscht
* die Daten von gesperrten Profilen werden nicht übergeben oder verschlüsselt übergeben.
1/x
@awlnx
> * Daten von gesperrten Profilen werden nicht übergeben oder verschlüsselt übergeben.
An dem Punkt lässt sich wahrscheinlich gerade hinsichtlich code reichlich feilen:
* Wie kommen nach Übergabe alte Nutzer noch an einen Download des gesamten (verschlüsselten?) Inhalts ihres Accounts und von wem?
* Wenn die Daten verschlüsselt übergeben bzw gedownloaded werden, wie kommen sie an den Schlüssel wer hält den?
* Die alten AGB sollten dem download beiliegen
2/x
@awlnx
* der alte Domain-Name muss ja übergeben werden um wesentlich grössere Komplikationen zu verhindern, Die Einrichtung einer neuen subDomain, um beim Beispiel zu bleiben, martinmuc.troet.cafe/AGBalt.troet.cafe müsste veranlasst werden.
* als einziger Ausweis der Identität kann nur die ursprüngliche und zum Zeitpunkt der Übergabe weiterhin geltende Emailadresse angesehen werden.
* jene Email könnte als CrossoverVerify bei alter/neuer Domain eingesetzt werden.
3/x
> * neue subdomain martinmuc.troet.cafe/AGBalt.troet.cafe
> * jene Email könnte als CrossoverVerify bei alter/neuer Domain eingesetzt werden.
Die Verifizierung auf der von der alten Instanz eingerichteten Subdomain durch die Emailadresse nach einer bereits erfolgten Übergabe bzw dem Inkraft treten der neuen AGB's würde dann entweder eine Freigabe der verschlüsselten Daten auf der übergebenen Instanz oder eine Übermittelung der selben zur Folge haben.
@Gargron @martinmuc
4/x
@awlnx
Das Thema "löschen" der Daten sollte gesondert betrachtet werden da "urplötzlich" die Daten zwei mal vorhanden sind.
Es ist offensichlich das:
a) was einmal imNetz ist, eingeschränkt publiziert oder nicht, immer im Netzt bzw öffentlich ist/werden kann
b) es hier grundsätzlich um das Thema vertrauen geht
Es sollte so sein das es ein "aktives" Verhalten der Parteien braucht, Codemanipulation oder herstellen einer Kopie, um das vollständige löschen zu verhindern.
@Gargron
@martinmuc
5/x
@awlnx
> das vollständige löschen
Vollständig löschen meint das letztendlich alle Daten und Kopien bei weiterführen des Kontos beim neuen Betreiber/AGB auf der subDomain des alten Betreibers/AGB gelöscht werden.
Wird das Konto nicht beim neuen Betreiber weiter geführt ergeben sich theoretisch zwei Optionen:
* vollständiges löschen aller Daten. Es müssten sinnvolle Zeitspannen definiert werden.
* einfrieren, sprich umwandeln in "static profile" auf subDomain
6/x
@awlnx
>"static profile"
Die meisten Kosten beim Betreiben von fediVerse Servern entstehen aufgrund von background tasks und Interkommunikation mit dem fediVerse. Speicherplatz wird nicht nur immer billiger, es gibt mitlerweile Anbieter die mit "free static page" Angeboten hausieren.
Nach der Übernahme von https://joindiaspora.org durch die Community hat sich vor kurzem ergeben das der Server als für zu veraltet im code und "Zeitaufwendig" galt, er ging vom Netz.
7/x
@awlnx
#Joindiaspora wurde "stillgelegt", und für einen darauffolgenden download der Profildaten modifiziert und eingefroren.
Die Profile wurden nicht in static pages umgewandelt, war nicht möglich oder zu kompliziert. Als Meilenstein in der Geschichte des Internets und #fediVerse an sich sehr schade. Toot's automatisch nach X-Tagen löschen ist im Falle von microblogging und dessen Verwendung eine verständliche Option, Initiativen wie https://archive.org jedoch auch.
@Gargron
@martinmuc
@awlnx
#Joindiaspora wurde "stillgelegt", und für einen darauffolgenden download der Profildaten modifiziert und eingefroren.
Die Profile wurden nicht in static pages umgewandelt, war nicht möglich oder zu kompliziert. Als Meilenstein in der Geschichte des Internets und #fediVerse an sich sehr schade. Toot's automatisch nach X-Tagen löschen ist im Falle von microblogging und dessen Verwendung eine verständliche Option, Initiativen wie https://archive.org jedoch auch.
@Gargron
@martinmuc
8/x
@awlnx
Die Option ein Profil in eine static pages umzuwandeln und dies im code der jeweiligen #fediVerse Plattform-Software anzulegen ist mehr als nahe liegend und eine interessante berechtigte Option die wahrscheinlich von vorne herein im main code angelegt werden muss. Ebenso wie die oben beschriebene Übergabe oder AGB-Änderungssequenz.
#Joindiaspora Posts sind noch auf anderen Servern vorhanden.
https://requeteche.tupambae.com ist eine Beispiel static page "saved as html".
9/x
@awlnx
Wenn ein Profil ein weiter führen des Accounts unter den neuen Bedingungen nicht zustimmen möchte entstehen folgende Optionen:
* redirect des Profils zur subDomain wenn dies als static profile pages bestehen bleibt und dies erwünscht wird mit entsprechendem disclaimer
* sperren des Profilnamens auf der alten domain die unter den neuen Bedingungen weiter besteht
* lockpage mit disclaimer des Profiles auf der Ursprünglichen domain wenn alles gelöscht werden soll