FMS (Java) design

From a discussion about the fms java port. Please discuss. We need
a final agreement how to implement it (as plugin, standalone, ...)


bbackde-gM/[email protected] 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.