Look at File Transfers for a pragmatic one-to-one file exchange strategy. It is a subset of what is needed to do friendcast-based File Sharing. This document is about the big picture as written up some time in 2003. See also Onion Routing and Friendivity.

OpenP2P on Next-Generation File Sharing with Social Networks

In the meantime we're pragmatic: File transfers by PsycZilla:Httpd.

File Sharing Manager

I'd like to add a thought: I'd like PsycZilla and other smarty clients to also keep track of unfinished and scheduled transfers so that a user may shutdown or crash her computer anytime and all intended transfers would still happen at a suitable time and speed.

Synchronizing Folders

Similar operation is to have folders on several systems synchronized via PSYC. You could either use a FUSE or the psycfilemonitor from perlpsyc to figure out when files are modified, then apply a binary delta algorithm and multicast the changes to all peers.

<Viaken> The rsync algorithm would be an obvious choice.

<lynX> If I'm not mistaken, rsync does a long comparison of files on both sides to find out what's changed. The idea here is to push changes rather than to figure them out later. A PSYC app should be told by the file system when things have changed, and act upon that.

This stuff is also mentioned on Software projects.

Document Sharing

keine angst. es wird sinnvoll.

psyc file sharing ist die tatsächliche umsetzung des privaten miteinander teilens von digitalen materialien unter personen die tatsächlich befreundet sind und ohne dass deren server, obwohl sie dezentral sind, irgendwelche konkreten dateilisten führen müssten. oder vielleicht doch? na mal schauen.

<el> ich bin sehr dagegen, dass die server irgendwelche dateilisten bereithalten. das führt zu rechtlichen problemen für serverbetreiber. ausserdem können wir besser. Ob man irgendwann nochmal räumen beibringt, suchanfragen usw zu regeln ist dann ja im prinzip was anderes. Nur wäre mir das als standard ein wenig zu "wild".

jedenfalls will ich vorerst eher eine art aufgemotztes DCC.. dateien austauschen mit freunden, anbieten, und regexp-suchen im freundeskreis. manche dateien sind für bestimmte leute, andere für alle die man so kennt.

mir schwebt etwas vor was irgendwo zwischen http, dcc, soulseek und audiogalaxy steht.

von http soll es die eigenschaft der einfachen adressierung erhalten.

ein pfad hinter der UNI einer person kann einen pfad auf dessen festplatte bedeuten, oder man kann einen request nach files hinschicken, die dann von der location beantwortet werden.

<el> ich wär dafür, dateien von ihrem namen zu entkoppeln. vielleicht sogar bestimmte dateien von mehr (mp3s von ihrem namen und ihrem id3) und nur mit md4-hashes zu arbeiten. das verbaut uns nicht die möglichkeit später downloads von mehreren quellen zu erlauben, ohne inkompatibel zu werden. Dann reicht es nämlich aus, wenn clients suchanfragen mit file-namen und den zugehörigen hashes ausliefern und in der lage sind Teile von Dateien anhand ihres hashes auszuliefern. Ob ein anderer client dann alles von ihnen läd oder nur bytes 34 bis 56 is dann schnurz. Ausserdem können wir onion-routing dann als reinen mmp-aufsatz betrachten, der sofort mit den schon bestehenden file-sharing anwendungen funktioniert (vorrausgesetzt die library kümmert sich drum).

von dcc soll es die stärke übernehmen im client zu laufen,

man muss seine daten nicht auf einen server uploaden, der request mag noch über die UNI laufen, aber ob passende dateien da sind weiss der client.

von soulseek soll die stärke kommen, verzeichnisweise navigierbar zu sein.

mittels psyc fragments ist die datentransferrate steuerbar.

von audiogalaxy wäre die geschickte umsetzung als daemon denkbar,

wodurch der user nonstop in der psyc-welt erreichbar ist für IM, jederzeit fenster für chaträume aufmachen kann, und freundesfreunde jederzeit dateien transferieren können. dies gilt sowohl für windows als unix-clients. wenn die software ganz selbstverständlich laufen gelassen wird, erhöht es die brauchbarkeit des dienstes dramatisch.

<el> die sache mit dem daemon ist gut. wir haben ja irgendwann schonmal file-sharing als service eingeführt. den muss man dann nur bei seiner uni registrieren und die liefert dann ip:port auf anfrage an die freunde aus.

beispiel:

.
_nick           heldensäga
_match_regular  (first men on pluto|FMOP)
_use_flags_match        _ignore_case
_request_file
[_nick] would like to know if you have any files matching [_match].
.

wobei die nachricht normalerweise automatisch verarbeitet wird, und nicht dargestellt wird:

nachsehen ob die regexp (a) die diesem user zugänglichen dateien matcht (b) irgendwelche dateien matcht aus einer grossen archivdatenbank, dessen medien nicht notwendigerweise zugänglich sein müssen. daraufhin: (a) datei ausliefern oder schnauze halten. beantworten mit _failure nur falls der request explizit nur an dich ging. in der regel kommt er über räume oder friendcast-channels. (b) falls datei exportiert, ausliefern - sonst eigentümer fragen, ob er seinem freund [_nick] die datei zugänglich machen will - wenn ja, file requester auf.