Re: FMS (Java) design

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

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
> [email protected]
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHyrgqalr61WGRfZARAoI7AJ45C7rqFDy7bAyngytSmbkxFrc/2QCg0Rmr
Xw1uBhLvUIVpHxqF81g/WSg=
=JdhX
-----END PGP SIGNATURE-----