bbackde at googlemail.com a ?crit : > From a discussion about the fms java port. Please discuss. We need > a final agreement how to implement it (as plugin, standalone, ...) > > > bbackde at googlemail.com wrote: >> While I think about it, maybe the best idea is to have your fms code >> running inside the >> node (as a plugin). The plugin provides only an FCP2 interface. All >> other interfaces should >> be on top, e.g. NNTP provided by another plugin, and Frost would use >> FCP2 commands >> to access your fms library code. >> >> What about this? I could help with the FCP2 interface, and we can >> remove all other interfaces >> from the code... >> >> > I think it's a good idea with a few "but".
I agree. I always thought it was the node's job and client applications should concentrate on "shiny" interfaces. > 1) The question is - do you think it should handle everything, > including messaging ? > That would be: > - Management of local identities (create/delete/change properties) > - View/editing of trusts (in my version TrustList is a part of local > identity) > - Introductions of new local identities and accepting introductions from > others > - Messaging (should the messaging store be on the node ? ) In my opinion, trusts should be handled by an independant plugin, so it could be used by other apps. Most apps need a WoT and it would be a waste of time (and maybe a security risk) if each developper had to write his own. I might work on it but not right now : I've got another project to finish first. > 2) [BIG issue] If messages store is on a Freenet node and not in Frost > folder, a node cannot be shared by two or more people. > I know that people _do_ share freenet nodes. > For example, Tin0 from Germany offers access to his Freenet node on > http://i2p.to/ and people run Frost agains it > without running own node. While not a good idea from privacy point of > view and risky for operator because of Vorratsdatenspeicherung & co, > sharing a node is a way to get more newbies onboard. Maybe it's possible to tag messages for a client ID, as we do with private download queues. > 3) [Small issue] Can we make protocol flexible enough that it can handle > possible changes in FMS ? > FMS is very much under development - we just recently changed the > MessageId format to avoid hijacking, > people want audio-captchas, I will propose a change to announce solved > captchas (people re-solve the same capthcas again and again > which is kinda stupid) > So there are changes and protocol should be flexible enough to handle them. > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20080302/1d4c0ba2/attachment.pgp>
