On Saturday 14 November 2009 16:47:27 bbackde at googlemail.com wrote:
> Great ideas from Toad and you.
>
> But there is one big problem: we are quite late in the development
> cycle. We wanted to
> finish a working version till Christmas. Your new ideas would mean to
> make a big step backward
> and start another design from scratch (however, there isn't no design
> yet for the new ideas, only problems ;) ).
I'm not sure that is true. The mentioned code duplication in Freetalk hasn't
been implemented yet afaik, and there are at least two WoT-based plugins making
rapid progress other than Freetalk, hence the issue coming up in the first
place.
>
> When we containue as planned we wil release something that is surely
> not compatible with the new ideas.
> And clients will use the new interface and implement it the way you don't
> want.
>
> So the question is: start again with new design, or complete something
> that works soon?
> Or is there a way for both?
I am not sure that there is a fundamental problem here, isn't this mostly a
matter of interfaces and of stuff that hasn't been implemented yet such as the
Freetalk UI to WoT?
>
> On Sat, Nov 14, 2009 at 17:36, Evan Daniel <evanbd at gmail.com> wrote:
> > On Sat, Nov 14, 2009 at 10:08 AM, Matthew Toseland
> > <toad at amphibian.dyndns.org> wrote:
> >> Currently Freetalk duplicates - or is planned to duplicate in the near
> >> future - most of the functionality of the Web of Trust plugin e.g. it will
> >> have identity pages with message counts etc. The plan is/was to hide the
> >> Web of Trust plugin and just have everything under the Discussion menu.
> >>
> >> However, there are two additional plugins under heavy development which
> >> use WoT:
> >> - digger3's WoT-based IRC system. This uses WoT for spam-resistant
> >> discovery.
> >> - Artefact2's FlogHelper blog tool, which uses an identity from WoT to
> >> simplify key management and eventually to avoid the need to announce the
> >> site and to tie in with Freetalk for feedback.
> >>
> >> Plus, hopefully:
> >> - infinity0's distributed searching functionality in Library.
> >> - evanbd's Fritter microblogging app.
> >> - Private messaging functionality in Freetalk or a new WoT-based Freemail
> >> version.
> >
> > So far I've been successful at slowly convincing digger3 to implement
> > most of the protocol-level ideas in my Fritter draft spec. ?I'm
> > hopeful that the two overlap enough that (eventually) the only
> > difference between Freenet-IRC and Fritter would be the interface.
> > Conceptually, this is fairly easy: both are a collection of short
> > messages posted by users, and both need to solve the problem of low
> > latency messages without insane amounts of polling. ?The same
> > related-links structure from Fritter works well with IRC. ?IMHO you
> > can treat IRC as simply a different interface to a subset of the
> > Fritter functionality: IRC messages must have exactly one hashtag,
> > which is the name of the IRC channel. ?(Then there's all the channel
> > moderator stuff like banning and topics, but I suspect that gets done
> > in a decentralized fashion that amounts to individual clients paying
> > attention to what the moderator publishes.)
> >
> > So I'm hopeful that digger3 will implement most or all of the Fritter
> > functionality while I continue trying to figure out how to take
> > meaningful statistics, and that at most it would just be a few changes
> > to the IRC plugin.
> >
> >>
> >> And probably more in future.
> >>
> >> Two basic problems here:
> >> 1. Code duplication: All these apps will need to duplicate much of
> >> Freetalk's duplicated WoT stuff (e.g. nagging the user if their identity
> >> hasn't been announced, setting trust etc). Most of them don't gain much
> >> benefit from this.
> >> 2. The same identities will be reused for multiple applications, and it
> >> should be easy to go from one to the next.
> >
> > I'm against code duplication, and I'm strongly against have different
> > UIs that do the same thing -- especially if changing something in one
> > UI means it changes in the other! ?I'm also in favor of reusing
> > identities -- publishing a flog under the same SSK I use to insert
> > Freetalk messages and IRC messages is a good thing.
> >
> > Note that this brings up the past discussion of trust contexts. ?My
> > recollection of that is we decided there was no reliable way to apply
> > trust ratings outside of the context they came from (when they come
> > from other people, that is -- if I trust / distrust a person locally,
> > it probably does make sense to apply that to all contexts). ?Any
> > unified UI would need to handle this properly. ?(And no, I don't have
> > any good suggestions for how. ?I'm also skeptical that it can be
> > meaningfully simplified and retain its usefulness.)
> >
> >>
> >> IMHO the solution to both problems is to keep the Web of Trust plugin
> >> visible, and make it easy to use. We might want to rename it ("Anonymous
> >> Friends"? Any other ideas?). It is essentially an anonymous social
> >> networking system: Each user has 1) various applications, and 2) trust
> >> relationships with other users.
> >
> > I dislike overloading the word "friend" between darknet peers and
> > on-Freenet identities. ?I propose "contacts" for the latter.
> >
> >>
> >> So, the profile page for a Known Identity should have links (and possibly
> >> detailed information) for each of the user's contexts. So for Freetalk,
> >> there would be how many messages he has posted, possibly a list of recent
> >> messages and/or commonly posted to boards, and/or a link to a page in
> >> Freetalk containing such information. For FlogHelper, there would be a
> >> link to the identity's one and only flog. For private messaging, there
> >> would be the ability to send a private message (whether by a link or
> >> inline). And so on.
> >>
> >> We would keep the existing trust setting functionality, and we would have
> >> a similar page for each of our Own Identities. In fact, we would probably
> >> only need one menu item for Web of Trust, which would be a merger of Own
> >> Identities with Known Identities: A list of Your Anonymous Identities,
> >> click on one to go to its profile page, with the option to add more.
> >>
> >> The big gain is that you can find a message on Freetalk, click on its
> >> author and send him a private message, change his trust levels, read his
> >> flog, chat with him in real time, search or browse his published files
> >> etc. This makes the Web of Trust plugin both useful and easy to use.
> >
> > I agree, this would be excellent!
> >
> >>
> >> We should be able to set the trust level from the own identity which is
> >> logged in to the identity whose profile page we are looking at *on that
> >> page*. We should probably also have some indication of how much we trust
> >> the other identities listed on that page: although this complicates the
> >> UI, it is very important practically IMHO.
> >>
> >> As p0s has rightly pointed out, when we go from Freetalk to a specific
> >> identity's page, our main concern is him in the context of Freetalk: We
> >> need to be able to see how many messages he has posted, and how many
> >> messages those who trust him have posted, as well as their trust levels
> >> etc. The current plan is to implement this page in Freetalk, fetch the
> >> data we need from WoT, add what we know from Freetalk, and show a
> >> Freetalk-focused page on that user. We can continue to do this, we just
> >> need to fetch a little more from WoT: The links to the other apps. However
> >> I expect that most WoT-based plugins will just use the WoT identity page.
> >
> > Click the name, get a freetalk-specific page that also has a link to
> > "view more about this contact" or something that shows the full WoT
> > page? ?That would also provide other application-specific links.
> >
> > Evan Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20091114/be9e3600/attachment.pgp>
