2008/3/2 Julien Cornuwel <batosai at batosai.net>:
> 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.

But this would require the node to fetch and store messages for ALL existing
boards and identities. Just for the case that someone maybe wants to see it.
This is a big change from the current situation (frost and fms), where
you can choose
to ignore boards and identities and we do not have to request the
boards/identities at all.

>
>
>  > 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
>
>
>
> _______________________________________________
>  Tech mailing list
>  Tech at freenetproject.org
>  http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
>



-- 
__________________________________________________
GnuPG key:   (0x48DBFA8A)
Keyserver:   pgpkeys.pca.dfn.de
Fingerprint:
477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A
__________________________________________________

Reply via email to