2010/11/10 Matthew Toseland <toad at amphibian.dyndns.org> > On Saturday 06 November 2010 19:39:09 cvollet at gmail.com wrote: > > 2010/11/6 Ian Clarke <ian at locut.us> > > > > > On Sat, Nov 6, 2010 at 12:24 PM, Matthew Toseland < > > > toad at amphibian.dyndns.org> wrote: > > > > > >> Awesome. I'm having difficulty viewing the svg's due to local > technical > > >> problems. It might save me time if you could post JPEGs or something? > > >> > > > > > > +1 for jpeg or png, I've tried viewing these in several different apps > and > > > they look screwed up in all of them. > > > > > > Yep, dunno why I didn't do that directly... (and svg should open fine > in > > inkscape). > > Anyway, see attached. > > Ooooh, interesting. > > Thanks, wasn't sure it would be appreciated.
> First, IMHO passwords should be optional. Maybe even configurable based on > initial seclevels. We are not going to have separate client layer databases > for each user, since we want everyone's downloads to work simultaneously - > and most nodes will have one user, who may have multiple accounts for e.g. > different chat pseudonyms. If passwords are disabled, we can have a simple > dropdown login. > > I'm not sure we should allow password-less accounts, maybe it makes sense for users who don't really care about their anonymity though. We should add a warning if they want to have a non protected access to their account. Regarding the one-account/one-client-layer I agree. But one user shouldn't be able to eavesdrop another user's download. What do you mean by dropdown login? If it's presenting user with different possible login, I disagree, we should let the browser manage that. Like in linux, if you don't know the username, well, too bad. Or, we could add another layer => account => identity. Dunno if it makes sense. > Second, I like the idea of having a traffic light for darknet vs opennet vs > connection problems. I'm happy to defer to folk who better understand > usability on how to deal with system notifications, just as long as we do > deal with them. > > I don't have in mind any notification that can't be addressed to a specific group of users. Do you have something in mind. (btw, and I don't know why I didn't ask before, nor why I do ask now, but if someone could forward this mockup to FMS/Freetalk/Frost, and have feedback from community (even if this doesn't concern the apps currently covered by the mockup), it would be great :) > I like the idea of searching forums, mails and friends. This implies adding > more functionality, of course... A publish-to-friends files list, Freemail > with a web interface and searching, and searching in Freetalk, and a way to > tie them all together. Also eventually we will have WoT-based search - we > still need to solve the "darknet friends" versus "anonymous friends" naming > issue. > > I let that to native english speaker ;) > I'm not sure how much social-style functionality we want at the darknet > level, since it's only visible to our friends? Although it might be > propagated further configurably if some users wanted that? Not sure whether > "user groups" makes sense... > > Well, the idea behind user groups is to allow pure-darknet users to use it event if they don't want to use WoT. For instance: I use darknet, I use WoT because (fill in a reason), but I still want that some informations I provide are relayed by my friends only (or the friends of my friends, etc.). I have one problem though. How can we identify a darknet user who don't want to use WoT but who still want his darknet "account" to be secure (i.e. I'm a darknet user, but I don't want that people having access to my computer being able to access my freenet session)? > For anonymous WoT-based peers, we need a profile page for each of the peers > on the WoT, with trust levels, applications, any social stuff they publish > etc... > Is that a problem? (I'm asking seriously, I don't have any idea) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101111/d57b2457/attachment.html>
