>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". 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 ? ) 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. 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.
