@mickylindlar
Komme gerade erst dazu, meine Notizen auszuformulieren, weil ich saß auch in der Session und habe am letzten Tag der #BiblioCon26 selbst noch was zu #SciOp gemacht. Vorausgeschickt: Ich beschäftige mich primär mit dem Datenhaltungsaspekt von dezentralen Technologien und nicht LZA. Also hier mal ein Feedback von mir aus der zweiten Reihe:
Trotz vieler Beteuerungen fürchte ich, dass durch die beiden ersten Beiträge bei vielen der Eindruck eines Gegensatzes zwischen #BitTorrent und #IPFS entstanden ist. @Lambo hat ja bewusst drauf verzichtet, BitTorrent zu erklären. Im zweiten Beitrag wurde auch die Funktionsweise von IPFS nicht erklärt. Und das ist eben schwierig, wenn zwei Technologien in den Raum gestellt werden, die das selbe Problem lösen sollen und sich dann aufeinander beziehen. So zumindest aus meiner Sicht einer IT-Person, die das dann an der eigenen Institution implementieren wollen würde. Ich hoffe mal, die beiden Technologien sind soweit bereits in der LZA Community bekannt, dass das Publikum auch folgen konnte. Bei SciOp ist das Einbinden von CIDs ja bereits möglich, habe ich z. B. bei meinem Upload demonstriert, weil ich betreibe selbst einen IPFS-Knoten: https://sciop.net/datasets/safeguarding-research-and-culture-sciop-article-2026-german-preprint
Wenn IPFS sich manuell per Metadaten bei einer SciOp-Instanz einbinden lässt, wäre es genauso möglich, dass in eine IPFS-Extension auszuweiten, bei der das alles automatisiert mit IPFS gesynct wird. Dann hängen noch die Institutionen ihre Preservation Systeme dran und wir haben auf SciOp das beste aus drei Welten. Die Klarheit über diese jetzt bereits bestehende Möglichkeit hat mir irgendwie gefehlt oder sie ist untergegangen.

@RenkeSiems hat die harten berechtigten Fragen zu BitTorrent gestellt, was ich sehr wichtig fand.
Ich habe mich nicht geäußert, weil ich nicht aufgezeichnet werden will, deswegen noch ein paar Anmerkungen zu beiden Beiträgen:
1) Über BitTorrent geteilte Daten sind leider durchaus korrumpierbar, zumindest im momentan etablierten Protokoll, das auf SHA1 basiert: https://tixati.com/specs/bittorrent/sha1_problems
Auch deswegen versucht SciOp, BitTorrent v2 zu etablieren, das neuere Kryptoalgos verwendet, aber leider wiederum andere Nachteile hat: https://sciop.net/docs/intro/bittorrent_v2/
2) Dem Problem des Trackings über BitTorrent wird heutzutage mittels VPNs oder TOR und Seedboxes begegnet. Das wäre sehr wichtig, das mit einer Guide und Hinweisen bei SciOp hervorzuheben, weil wir davon ausgehen müssen, dass hier auch gezielt IPs gesammelt werden und Menschen in den USA sind da besonders gefährdet.
3) Ein essenzielles Problem von IPFS ergibt sich aus der Praxis, wenn man als Institution selbst einen Knoten betreiben will. (Sidenote: Ich war vor paar Jahren an einer Implementierung von IPFS in DSpace beteiligt, die aber nicht weiterverfolgt wurde.) Wer einen IPFS-Knoten betreibt, der am globalen IPFS-Netzwerk angebunden ist, hostet auch zwangsläufig Daten von Unbekannten. Dabei kann es sich auch um justiziable Inhalte handeln. Es ist zwar möglich, das nahezu zu minimieren, aber das Problem ist, dass die gängigen IPFS-Clients es nicht vorsehen, nur die eigenen Daten zu teilen. Bei uns hatte das letztendlich dazu geführt, eher den Betrieb eines geschlossenen Netzwerks von eigenen IPFS-Knoten in Erwägung zu ziehen, was überhaupt erst Sinn ergeben hätte, wenn andere Wissenschaftsorganisation mit Knoten dazu gestoßen wären, zumindest nach meinem Verständnis von Dezentralisierung.
4) Die Annahme, CIDs wären wie Hashes oder "Links, die auf ewig halten" (Zitat Cornelius Ihle), will ich so nicht stehen lassen. Es gibt jetzt schon mehrere Versionen von CIDs. Und selbst ich habe Probleme, ohne meinen Knoten "alte CIDs" zu reproduzieren, weil ich dann irgendwelche custom libraries der IPFS devs rauskramen muss. Sobald kubo (die etablierte IPFS-Knoten Software) bestimmte CID-Versionen nicht mehr unterstützt, sind diese auch nicht mehr resolvable, also abrufbar. Für wirklich langfristig reproduzierbar halte ich nur die statischen Hashes der etablierten Kryptoalgos (CRC, MD5, SHA, BLAKE ff.), weil diese libraries breit bis in die Betriebssystemebene eingebettet sind - aber die sind eben nicht resolvable. Es gibt zwar noch per DNS anbindbare Varianten von Decentralized Identifiers (DIDs), die Hashes resolvable machen können, aber das wäre dann noch mal eine andere Diskussion.

#SafeguardingResearch #DataRescue #Langzeitarchivierung #LZA #DigiPres #DigitalPreservation #FDM #FAIRdata #PIDs #OpenAccess #OpenScience #DigitaleSouveränität #UnplugBigTech #UnplugTrump #GLAM #Bibliotheken #DigitalHumanities #AcademicChatter