[freenet-dev] Where to put GWT?
* Matthew Toseland [2009-05-23 20:43:56]: > sashee is working on making the web interface more dynamic. Google Web > Toolkit will be used to translate some java code into javascript, and then > this generated javascript will be built into Freenet in much the same way as > themes are. > > The problem is that we need to be able to rebuild it when somebody does an > ant distclean, e.g. when creating a signed jar to distribute as a stable > build. > > IMHO the best option is to put GWT, in source code form, without the platform > speciifc stuff (apparently we only need two jars to compile java into > javascript, they add up to 15MB), into the contrib repository, thus keeping > the fred repo clean. There is already a lot of third party code in the > contrib repository, and it is quite large, so IMHO this is not a problem. > Then when you do ant distclean in fred, it will wipe the generated > javascript, and then when you run ant, it will rebuild it. If contrib is not > unpacked in ../contrib then the build will fail. > > Another option would be to include the compiled jars in contrib (bad if you > want to do a full rebuild), or to just require GWT to be unpacked in ../gwt . > Any objections to my proposal, or support for other options? Make ant download the appropriate version of GWT if needed. That's what we use to do with the wrapper and other dependancies. NextGen$ -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/dd19af3f/attachment.pgp>
[freenet-dev] Where to put GWT?
sashee is working on making the web interface more dynamic. Google Web Toolkit will be used to translate some java code into javascript, and then this generated javascript will be built into Freenet in much the same way as themes are. The problem is that we need to be able to rebuild it when somebody does an ant distclean, e.g. when creating a signed jar to distribute as a stable build. IMHO the best option is to put GWT, in source code form, without the platform speciifc stuff (apparently we only need two jars to compile java into javascript, they add up to 15MB), into the contrib repository, thus keeping the fred repo clean. There is already a lot of third party code in the contrib repository, and it is quite large, so IMHO this is not a problem. Then when you do ant distclean in fred, it will wipe the generated javascript, and then when you run ant, it will rebuild it. If contrib is not unpacked in ../contrib then the build will fail. Another option would be to include the compiled jars in contrib (bad if you want to do a full rebuild), or to just require GWT to be unpacked in ../gwt . Any objections to my proposal, or support for other options? -- 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/20090523/b615150a/attachment.pgp>
[freenet-dev] Some French translations
On Saturday 23 May 2009 17:02:47 3BUIb3S50i 3BUIb3S50i wrote: > Some French translations. > Pushed to git. -- 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/20090523/7e0f2a98/attachment.pgp>
[freenet-dev] ITA l10n update 090523
On Saturday 23 May 2009 16:22:16 Luke771 wrote: > updated to r23771 > please commit > Pushed to git. -- 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/20090523/280beec9/attachment.pgp>
[freenet-dev] Why WoTs won't work....
On Sat, 2009-05-23 at 15:06 +0100, Matthew Toseland wrote: > On Saturday 23 May 2009 10:43:09 Arne Babenhauserheide wrote: > > On Friday, 22. May 2009 23:10:42 Mike Bush wrote: > > > I have been watching this debate an I was wondering whether it could > > > help to have 2 sets of trust values for each identity in a trust list, > > > this could mean you could mark an identity as spamming or that I don't > > > want to see these posts again as i find them objectionable. > > > > This is what Credence did in the end for spam detection on Gnutella, so it > > might fit the human psyche :) > > > > People got the option to say "that's bad quality or misleading", "I don't > > like > > it" or "that's spam". > > > > For messages that could be > > > > * "that ID posts spam" > > * "that ID posts crap" > > > > The first can easily be reviewed, the second is subjective. That would give > > a > > soft group censorship option, but give the useful spam detection to > > everyone. > > > > Best wishes, > > Arne > > > > PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the > > mail's > > useful to you nontheless. > > People will game the system, no? If they think paedophiles are scum who > should not be allowed to speak, and they realise that clicking "This is spam" > is more effective than "This is crap", they will click the former, no? Yes but offering this could separate those who wish to mark what they are objected to and don't wish to see from those who wish to censor other peoples views of the service against their will. I don't think the first group should be a problem if they have this option. Surely it depends on what proportion are in each group, I've not used FMS, maybe someone who uses it has some idea whether these groups exist.
[freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday 23 May 2009 10:48:18 Arne Babenhauserheide wrote: > On Friday, 22. May 2009 23:38:35 Matthew Toseland wrote: > > Putting the messages only here is a bad idea. Some of these messages are > > IMPORTANT. What we need to do is: - show the summary on the Browse Freenet > > page and maybe others > > - reduce the number of messages by coalescing them and shifting them to the > > relevant pages: "You have 6 messages" with a link to the Friends page > > rather than one for each n2ntm, similar with bookmark updates. > > I personally like having the messages at the top. > > freind to friend messages are the major way to keep in contact with your > friends, and the friends are important, so their messages should be visible > instantly. > > If a friend says "I've been compromised" every other user HAS TO see that on > the first page. Well, no other alert is shown in full at the moment. Isn't it better to just say "You have 5 messages from friends" ? Or "You have 1 new messages from friends" ? -- 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/20090523/6a38bc77/attachment.pgp>
[freenet-dev] Some French translations
Some French translations. -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/458fa772/attachment.html> -- next part -- A non-text attachment was scrubbed... Name: freenet.l10n.fr.override.properties Type: application/octet-stream Size: 2350 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/458fa772/attachment.obj>
[freenet-dev] ITA l10n update 090523
updated to r23771 please commit -- next part -- An embedded and charset-unspecified text was scrubbed... Name: freenet.l10n.it.override.properties_090523_luke771 URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/8b7ddbe3/attachment.ksh>
[freenet-dev] Why WoTs won't work....
On Sat, May 23, 2009 at 10:06 AM, Matthew Toseland wrote: > On Saturday 23 May 2009 10:43:09 Arne Babenhauserheide wrote: >> On Friday, 22. May 2009 23:10:42 Mike Bush wrote: >> > I have been watching this debate an I was wondering whether it could >> > help to have 2 sets of trust values for each identity in a trust list, >> > this could mean you could mark an identity as spamming or that I don't >> > want to see these posts again as i find them objectionable. >> >> This is what Credence did in the end for spam detection on Gnutella, so it >> might fit the human psyche :) >> >> People got the option to say "that's bad quality or misleading", "I don't >> like >> it" or "that's spam". >> >> For messages that could be >> >> * "that ID posts spam" >> * "that ID posts crap" >> >> The first can easily be reviewed, the second is subjective. That would give a >> soft group censorship option, but give the useful spam detection to everyone. >> >> Best wishes, >> Arne >> >> PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's >> useful to you nontheless. > > People will game the system, no? If they think paedophiles are scum who > should not be allowed to speak, and they realise that clicking "This is spam" > is more effective than "This is crap", they will click the former, no? I would assume that's the normal case. OTOH, there isn't much harm in implementing it, and if some people use it, that would help somewhat... Perhaps implement, but not required for initial release? Evan Daniel
[freenet-dev] Why WoTs won't work....
t everyone will have to mark all the spam identities as spam, much as in > > Frost with the Alice bot. It will deter newbies, but it should be usable > > for the determined. Note that it is *essential* on a positive trust only > > network that our spam markings override others' positive trust levels. > > > > The second approach is when we mark an identity as spam, WoT realises that > > an identity trusting that spammer also trusts a lot of other spammers, and > > proposes that we mark the parent identity as a spammer, at least for > > purposes of trust list trust. Hopefully this will be enough. The cost for > > every user will be to mark a few spammer posts as spam, and then accept > > WoT's recommendation to mark the parent as spammer. "A few" will be an > > arbitrary parameter that will have to be argued about, higher means less > > chance of marking non-spammers as spammers, but at the cost of seeing more > > spam. > > > > The third approach is that when we mark the parent identity as spam, WoT > > suggests marking those who trust the parent identity also as spammers for > > purposes of trust list trust (if we trust them; if we don't, it's not our > > problem; we are trying to optimise the network *for other people*, > > particularly for newbies, here). We can try to be polite about this using > > ultimatums, since it's likely that they didn't deliberately choose to trust > > the spam-parent knowing he is a spam-parent - but if they don't respond in > > some period by removing him from their trust list, we will have to reduce > > our trust in them. This will cause collateral damage and may be abused for > > censorship which might be even more dangerous than the current problems on > > FMS. However, if there is a LOT of spam, or if we want the network to be > > fairly spam-free for newbies, the first two options are insufficient. :| > > I'm not certain you're correct about this. The first two methods are, > imho, sufficient to limit spam to levels that are annoying, but where > the network is still usable. Even if they download a bunch of > messages, a new user only has to click the "spam" button once per > spamming identity, and those are limited in a well defined manner > (linear with modest coefficient with the number of dummy identities > the spammer is willing to maintain). > > My suspicion is that if all they can aspire to be is a nuisance, the > spammers won't be nearly as interested. There is much more appeal to > being able to DoS a board or the whole network than being able to > mildly annoy the users. So if we limit the amount of damage they can > do to a sane level, the actual amount of damage done will be > noticeably less than that limit. Can we agree that we should implement the second option in WoT then? > > There is another possible optimization we could do (I've just thought > of it, and I'm not entirely certain that it works or that I like it). > Suppose that Alice trusts Bob trusts Carol (legitimate but confused) > trusts Sam (a spammer), and Alice is busy computing her trust list. > Bob has (correctly) marked Sam as a spammer. In the basic > implementation, Alice will accept Sam. Bob may think that Carol is > normally correct (and not malicious), and be unwilling to zero out his > trust list trust for her. However, since this is a flow computation, > we can place an added restriction: when Alice calculates trust, flow > passing through Bob may not arrive at Sam even if there are > intermediate nodes. If Alice can find an alternate route for flow to > go from Alice to Carol or Sam, she will accept Sam. > > This modification is in some ways a negative trust feature, since > Bob's marking of Sam as a spammer is different from silence. However, > it doesn't let Bob censor anyone he couldn't censor by removing Carol > from his trust list. Under no circumstances will Alice using Bob's > trust list result in fewer people being accepted than not using Bob's > trust list. It does mean that Bob, as a member of the evil cabal of > default trust list members for newbies, can (with the unanimous help > of the cabal) censor identities in a more subtle fashion than simply > not trusting anyone. > > The caveats: this is a big enough change that it needs a close > re-examination of the security proof (I'm pretty sure it's still > valid, but I'm not certain). If it sounds like an interesting idea, I > can do that. Also, I don't think it's compatible with Ford-Fulkerson > or the other simple flow capacity algorithms. The changes required > might be non-trivial, possibly to the point of changing the running > time. Again, I could look at this in detail if it's interesting > enough to warrant it. Worth investigating IMHO. > > 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/20090523/2118273c/attachment.pgp>
[freenet-dev] Why WoTs won't work....
On Saturday 23 May 2009 10:43:09 Arne Babenhauserheide wrote: > On Friday, 22. May 2009 23:10:42 Mike Bush wrote: > > I have been watching this debate an I was wondering whether it could > > help to have 2 sets of trust values for each identity in a trust list, > > this could mean you could mark an identity as spamming or that I don't > > want to see these posts again as i find them objectionable. > > This is what Credence did in the end for spam detection on Gnutella, so it > might fit the human psyche :) > > People got the option to say "that's bad quality or misleading", "I don't > like > it" or "that's spam". > > For messages that could be > > * "that ID posts spam" > * "that ID posts crap" > > The first can easily be reviewed, the second is subjective. That would give a > soft group censorship option, but give the useful spam detection to everyone. > > Best wishes, > Arne > > PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's > useful to you nontheless. People will game the system, no? If they think paedophiles are scum who should not be allowed to speak, and they realise that clicking "This is spam" is more effective than "This is crap", they will click the former, no? -- 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/20090523/ee83a900/attachment.pgp>
[freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday 23 May 2009 11:04:12 Arne Babenhauserheide wrote: > On Saturday, 23. May 2009 02:20:23 Cl?ment wrote: > > > > A always seeable (sorry for new words...) button 'Shutdown the node' > > > > and 'Restart the node' > > > > > > You want to encourage people to shut down? IMHO the best way to do that > > > is with a system tray icon. > > > > Hum, in all application you can always exit the application in one click. I > > know freenet needs people to run it as long as they can, but hidding the > > shutdown button is not a solution (we don't want to force them to run > > freenet, do we ? ;) ) > > Why not just add a pause button to the ones on the start page? Because we haven't implemented pause yet? :) But yes, it's a good idea. > > The stop and restart buttons currently are on the first page. > > But maybe all these options could be moved to a "manage your node" or > "maintenance" page. Perhaps, or perhaps we need a status line, which could include simple vs advanced mode, color coded security levels, pause vs un-pause, shutdown, restart, language selector, and a count of non-serious alerts? This would not take up very much space vertically and could probably be manageable horizontally. > > Configuration, Statistics and Reachability could also go there. Yes, this probably makes sense. > > As addition: I think up- and downloads should be called up- and downloads - > regardless of how queuey they are :) Agreed. > Then they should also have a "download key" field like the one on the start > page. It could differ from teh one on teh start page by always downloading to > the download folder. Yes. Although we already have "Bulk Downloads", and we don't want to get rid of it ... maybe better document it? "Bulk Downloads" -> "Download files by key" ??? And then on the Browse Freenet page, "Fetch a Key (CHK, SSK, USK)" -> "Fetch a freesite by key" ??? -- 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/20090523/32005318/attachment.pgp>
[freenet-dev] Why current ui may be improved, and proposed improvements
is not yet available. Please use > > > ?jSite / Thingamablog / > > > the-other-freesite-manager-I-don't-remember-the-name? instead.' > > > Possibility to add some instructions, like how to make a freesite > > > available for all. > > > > Hmmm, not a bad idea. > > > > > ##Filesharing : > > > > > > On both pages, at the exact same place : > > > > > > Show the number of current downloads and uploads. > > > > And the total size, surely? > > Ah, yes. The aim here is to have a ui that looks a bit like a very simple > filesharing client, so we should always see a very short summary. > > We could add global dl/ul related bitrate (i.e. the sum of all per dl/ul > bitrate, not the global bitrate for all requests), but I don't know if it's > easily feasable. In the same way, we could show the current bitrate per dl/ul > in the appropriate page (instead of just the progression) We could ... or an ETA. It's likely to be rather disappointing either way, would it be an improvement? > > > > ###Downloads : > > > > > > Field bulk download; > > > > What does that mean? > > On the current downloads & upload page, there is a field 'bulk download'. > Just > reuse it here. > > > > Show the progress of downloads. > > > Propose to clear all the finished downloads. > > > > Possibly. One problem is it is possible to have downloads to temporary > > space, clearing them will actually *delete the data* so that it is no > > longer accessible. Whereas downloads to disk don't have this problem. > > However, you can only add downloads to disk through fproxy. IMHO we will > > still need to show the two kinds of downloads separately, and we will > > probably want to show finished downloads separately to in-progress > > downloads. > > Ok, I didn't thought about that. Separate the two kinds of downloads is not a > bad idea. > > > > Propose to clear or stop the downloads one-by-one (as now). > > > > Yes. > > > > > Add a checkbox to all downloads, and propose and action for the selected > > > dl (like in the connection to friends page). > > > > For selective deletion? Wouldn't it be better to have a "Delete some > > downloads" button or something that puts in the checkboxes? I mean in terms > > of UI obviousness? > > Hum, I don't know. For me it seems obvious that when you have checkbox before > an item it's for selection, but it might be confusing for people who aren't > familiar with webui. So, I don't know. We should experiment on this point, > and > ask users. > > > > ###Uploads : > > > > > > File : > > > Field 'Path' + Button browse. > > > Checkbox : upload through the browser > > > > This is possible with javascript. Without javascript we should show both > > versions, with an explanation. > > Ok, I thought it would be without javascript. Too bad, it would have made > things clearer. Well, javascript is now on by default, we should use it where possible. > > > > Insert as : > > > * CHK : explain what it is > > > * SSK/USK : idem > > > * KSK : idem + ask for the name > > > > Agreed, some self-documentation here is helpful, although it would make the > > form take up more space. > > I don't think space is a scarce ressource here. So it shouldn't be much of a > problem (besides, the explaination should fit in one or two lines) > Oh, and I almost forget : > we should have a distinct 'insert' button (in the current page, the button is > on the same line than the browse button iirc) Yeah ... but it means the box is going to take up a *significant* chunk of space, are you sure this isn't a problem? Well, with submenus, it could be a separate page anyway... > > > ###Statistics : > > > > > > sub-menu : > > > > > > node related things : (JVM + node version + datastore) > > > bandwith : bandwith usage + number of bits dl/ul > > > misc : cpu, threads, generate thread dump, etc. > > > > Agreed, we should split this up. But it's not important IMHO. Also, it's > > not a top level menu item, and we probably *don't* want the complications > > of three level menus. > > We can do this very simply. We just need to put the links to all statistics > category page on top of each statistics page. I don't know if I'm clear, so a > bit of html : You mean like we do on the Configuration page which you find difficult to use? If it's bad there then it's bad here. -- 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/20090523/0543f38c/attachment.pgp>
[freenet-dev] Why WoTs won't work....
On Sat, May 23, 2009 at 10:10 AM, Matthew Toseland wrote: >> > We want to make it easy, or nobody will do it. Poring over your trust list >> > day after day is not most people's idea of fun. >> > >> > There are three approaches, given positive trust only. Depending on the >> > level of effort exerted by the spammer, we move from one tradeoff between >> > spam resistance and censorship resistance to the next. IMHO the last stage >> > involves significant risk of censorship or at least collateral damage, >> > while obviously having the strongest spam resistance. >> > >> > The first approach is to mark spammers as spammers, and limit the capacity >> > of trusted identities to create new spammers by for example limits on the >> > number of identities that can change in a trust list in one day. This >> > means that everyone will have to mark all the spam identities as spam, >> > much as in Frost with the Alice bot. It will deter newbies, but it should >> > be usable for the determined. Note that it is *essential* on a positive >> > trust only network that our spam markings override others' positive trust >> > levels. >> > >> > The second approach is when we mark an identity as spam, WoT realises that >> > an identity trusting that spammer also trusts a lot of other spammers, and >> > proposes that we mark the parent identity as a spammer, at least for >> > purposes of trust list trust. Hopefully this will be enough. The cost for >> > every user will be to mark a few spammer posts as spam, and then accept >> > WoT's recommendation to mark the parent as spammer. "A few" will be an >> > arbitrary parameter that will have to be argued about, higher means less >> > chance of marking non-spammers as spammers, but at the cost of seeing more >> > spam. >> > >> > The third approach is that when we mark the parent identity as spam, WoT >> > suggests marking those who trust the parent identity also as spammers for >> > purposes of trust list trust (if we trust them; if we don't, it's not our >> > problem; we are trying to optimise the network *for other people*, >> > particularly for newbies, here). We can try to be polite about this using >> > ultimatums, since it's likely that they didn't deliberately choose to >> > trust the spam-parent knowing he is a spam-parent - but if they don't >> > respond in some period by removing him from their trust list, we will have >> > to reduce our trust in them. This will cause collateral damage and may be >> > abused for censorship which might be even more dangerous than the current >> > problems on FMS. However, if there is a LOT of spam, or if we want the >> > network to be fairly spam-free for newbies, the first two options are >> > insufficient. :| >> >> I'm not certain you're correct about this. ?The first two methods are, >> imho, sufficient to limit spam to levels that are annoying, but where >> the network is still usable. ?Even if they download a bunch of >> messages, a new user only has to click the "spam" button once per >> spamming identity, and those are limited in a well defined manner >> (linear with modest coefficient with the number of dummy identities >> the spammer is willing to maintain). >> >> My suspicion is that if all they can aspire to be is a nuisance, the >> spammers won't be nearly as interested. ?There is much more appeal to >> being able to DoS a board or the whole network than being able to >> mildly annoy the users. ?So if we limit the amount of damage they can >> do to a sane level, the actual amount of damage done will be >> noticeably less than that limit. > > Can we agree that we should implement the second option in WoT then? Yes, though I think it should default to only alerting the user in the case of relatively obvious abuse. As part of that I think it should give the identity in question a modest grace period to correct its trust list (if trust lists are published daily, 2 days seems appropriate). Given the churn rate limits, I don't think that's an issue. >> >> There is another possible optimization we could do (I've just thought >> of it, and I'm not entirely certain that it works or that I like it). >> Suppose that Alice trusts Bob trusts Carol (legitimate but confused) >> trusts Sam (a spammer), and Alice is busy computing her trust list. >> Bob has (correctly) marked Sam as a spammer. ?In the basic >> implementation, Alice will accept Sam. ?Bob may think that Carol is >> normally correct (and not malicious), and be unwilling to zero out his >> trust list trust for her. ?However, since this is a flow computation, >> we can place an added restriction: when Alice calculates trust, flow >> passing through Bob may not arrive at Sam even if there are >> intermediate nodes. ?If Alice can find an alternate route for flow to >> go from Alice to Carol or Sam, she will accept Sam. >> >> This modification is in some ways a negative trust feature, since >> Bob's marking of Sam as a spammer is different from
[freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday, 23. May 2009 02:20:23 Cl?ment wrote: > > > A always seeable (sorry for new words...) button 'Shutdown the node' > > > and 'Restart the node' > > > > You want to encourage people to shut down? IMHO the best way to do that > > is with a system tray icon. > > Hum, in all application you can always exit the application in one click. I > know freenet needs people to run it as long as they can, but hidding the > shutdown button is not a solution (we don't want to force them to run > freenet, do we ? ;) ) Why not just add a pause button to the ones on the start page? The stop and restart buttons currently are on the first page. But maybe all these options could be moved to a "manage your node" or "maintenance" page. Configuration, Statistics and Reachability could also go there. As addition: I think up- and downloads should be called up- and downloads - regardless of how queuey they are :) Then they should also have a "download key" field like the one on the start page. It could differ from teh one on teh start page by always downloading to the download folder. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/f7052434/attachment.pgp>
[freenet-dev] Why current ui may be improved, and proposed improvements
On Friday, 22. May 2009 23:38:35 Matthew Toseland wrote: > Putting the messages only here is a bad idea. Some of these messages are > IMPORTANT. What we need to do is: - show the summary on the Browse Freenet > page and maybe others > - reduce the number of messages by coalescing them and shifting them to the > relevant pages: "You have 6 messages" with a link to the Friends page > rather than one for each n2ntm, similar with bookmark updates. I personally like having the messages at the top. freind to friend messages are the major way to keep in contact with your friends, and the friends are important, so their messages should be visible instantly. If a friend says "I've been compromised" every other user HAS TO see that on the first page. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/3fcf7dfe/attachment.pgp>
[freenet-dev] Why WoTs won't work....
On Friday, 22. May 2009 23:10:42 Mike Bush wrote: > I have been watching this debate an I was wondering whether it could > help to have 2 sets of trust values for each identity in a trust list, > this could mean you could mark an identity as spamming or that I don't > want to see these posts again as i find them objectionable. This is what Credence did in the end for spam detection on Gnutella, so it might fit the human psyche :) People got the option to say "that's bad quality or misleading", "I don't like it" or "that's spam". For messages that could be * "that ID posts spam" * "that ID posts crap" The first can easily be reviewed, the second is subjective. That would give a soft group censorship option, but give the useful spam detection to everyone. Best wishes, Arne PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's useful to you nontheless. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/824a7d48/attachment.pgp>
[freenet-dev] New java-based installers
It's OK on Linux, but the installer and the "first time wizard" don't ask if I want auto-start (and I don't want auto-start). On Fri, May 22, 2009 at 9:08 PM, Matthew Toseland wrote: > The java-based installer has been updated. Windows users already see the > windows installer, this is for mac and linux users. The installer no longer > asks about auto-start, plugins or auto-update (all but auto-start are asked > in the first-time wizard), start on reboot support on OS/X should be fixed > thanks to mrsteveman, and we are shipping the offline installer, with all > the > dependancies included, except for in the jnlp version used for mac's (this > should probably be fixed soon). Both the wininstaller and the java > installer > are now being distributed via CoralCache, which can achieve good download > speeds, but a file cannot be updated easily once it has been published. > Because we are bundling all the dependancies in both the windows installer > and the java installer, it will need to be rebuilt for every new stable > build. > > If you have a mac, please test the installer. In particular, does Freenet > successfully restart after a reboot (it should start up during login). > > If you don't have a mac, testing would still be helpful. > > ___ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -- next part -- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090523/e0ceebf8/attachment.html>
[freenet-dev] New java-based installers
On Saturday 23 May 2009 10:40:07 3BUIb3S50i 3BUIb3S50i wrote: > It's OK on Linux, but the installer and the "first time wizard" don't ask if > I want auto-start (and I don't want auto-start). That's your problem. Use the provided script to remove the cron job. IIRC the script to remove the cron job doesn't remove the auto-launch on Mac yet, we should fix this. > > > On Fri, May 22, 2009 at 9:08 PM, Matthew Toseland amphibian.dyndns.org > > wrote: > > > The java-based installer has been updated. Windows users already see the > > windows installer, this is for mac and linux users. The installer no longer > > asks about auto-start, plugins or auto-update (all but auto-start are asked > > in the first-time wizard), start on reboot support on OS/X should be fixed > > thanks to mrsteveman, and we are shipping the offline installer, with all > > the > > dependancies included, except for in the jnlp version used for mac's (this > > should probably be fixed soon). Both the wininstaller and the java > > installer > > are now being distributed via CoralCache, which can achieve good download > > speeds, but a file cannot be updated easily once it has been published. > > Because we are bundling all the dependancies in both the windows installer > > and the java installer, it will need to be rebuilt for every new stable > > build. > > > > If you have a mac, please test the installer. In particular, does Freenet > > successfully restart after a reboot (it should start up during login). > > > > If you don't have a mac, testing would still be helpful. -- 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/20090523/a7c58929/attachment.pgp>
[freenet-dev] Why current ui may be improved, and proposed improvements
Le vendredi 22 mai 2009 23:38:35, Matthew Toseland a ?crit : > On Friday 22 May 2009 17:31:46 Cl?ment wrote: > > Hi all, > > > > First, let's see the current situation : > > > > > > #Navigation : > > > > 9 items is really the max we can afford. Currently there are 9 items, but > > they aren't all necessary, and can confuse the newbies. > > Agreed, we need sub-menus. > > > #Browse Freenet page : > > > > The ?Search Freenet? field and bookmarks are definitly a good thing. > > However, why do we have : > > ?Fetch a key? : we don't want to fetch a key, we want to browse Freenet. > > Some users DO want to fetch a key. But maybe it should be on the queue > page. > Yep, here I just list the points that I don't find logical. If we want to fetch a key, we go in the downloads page. If we want to visit a site, we need a box to do so (see below, I forgot to put that on the browse page proposition) > > ?Version Information & Node Control? : we don't care, we just want to > > browse Freenet. > > When they come to us, we usually need to know the version number. Sure, but I don't think it's the right place to put this information. It should be under the status/statistics page, or maybe we can add a submenu status/node info. > > > ?Current Activity? : idem > > Fair point. > > > #Messages : > > > > I agree we need to inform user when something is wrong. However, for the > > bookmarks, it's not the good place. > > I don't think either that there should be one page just for the messages > > : sometimes there is no message, it just wastes space. > > In which case we don't show the menu item. > Ah, my bad then. But it's not really better, since menu item shouldn't disappear : we need consistency over the time. One thing has exactly one place, and always the same. > If we put all the messages on the main page in full, they take up so much > space that newbies don't see the rest of the page. > Yep, that's not a solution. > There are a number of messages that take up multiple slots on the message > list when they should really just post a summary and point to another page > where they are in full (e.g. n2ntms should be on the friends page, bookmark > updates on the browse freenet page). > > We should probably either > 1) not link the messages page from the main menu, but keep it, or > 2) make messages expand themselves when you click on them > > > #Download and Upload : > > > > No clear separation between dowloads and uploads. > > Agreed. WHEN we have sub-menus, we should separate the two. > Sub-menu should be easy to implement. > > #Plugins : > > > > This is a mess : here we access the plugins, we can add an official > > plugin, we can add a plugin from an url, we can add a plugin from > > freenet. > > It is not very user-friendly, because the box doesn't tell a newbie very > much, and the dropdown for official plugins doesn't give any indication > what they do. However, the functionality is important. We may want to split > this into multiple pages under a sub-menu, but we certainly want to > document the official plugins. > Yep, see the Configuration/Plugin page. > > #Connections to friends + connections to strangers : > > > > Why 2 separate pages ? > > Because they are different! Friends and Strangers are completely different > IMHO. Friends have names, you can send them text messages, etc. Strangers > are just numbers - normal users don't care about their IP address, etc. > Hmm, ok. > > Why showing informations about the current activity of > > the node ? > > Good question. Some of it is per-node so clearly has to be here (but only > in advanced mode), but the status at the top is debatable. > It's redondant information yes (I mean the status). > > All is mixed : managing nodes (adding/deleting) and showing their status. > > Why are the ports showed ? > > Where do you propose we put them? On the Internet Connection page, I guess? > Some users will need to know them for port forwarding reasons. > Maybe on the Status/node info page then. (I forgot that point in my proposal) > > #Statistics : > > > > Nothing to say. It's just statistics. Maybe divide in several category. > > It's huge yeah, it should probably be split eventually. > > > #Internet Connection : > > > > ??? It doesn't even work here... And when it works, it shows debug > > informations or really advanced ones. Why a level 1 page for that ? (why > > a page for that in fact..) > > In "Simple interface", my node shows: > > Connectivity > UDP Darknet port 24374Port forwarded > UDP Opennet port 37024Maybe port forwarded > > This is not immediately comprehensible by a new user. We will tell the user > that they need to forward specific ports with a useralert if we need to. > However, this information may be of use somewhere, it should probably be > hidden away though. > I'm not saying that these informations aren't usefull. They're just not in the right place (imo). > > #Configuration : > > > > A big big mess. Really. When in
[freenet-dev] Why WoTs won't work....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > In contrast, Advogato has multiple levels of trust, and each identity > either trusts or does not trust each other identity at a given level. ... > This implies running Ford-Fulkerson or similar; it's more complicated > than the current system, though not drastically so. > http://en.wikipedia.org/wiki/Ford-Fulkerson_algorithm I don't know if it's common knowledge, but there's a relatively well-written implementation of Advogato trust metric in Java, available here: http://www.saddi.com/projects/index.html. I hadn't reviewed it personally, but several of my students used it successfully in their trust-related research. Regards, Victor Denisov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKFxl6x7AVSvyjsUARAld2AJ0aFU+OB7M7r2EQ2Z+UGDuK9G8OAwCeORwe Ye1A8m+eGgr6IOdnqWtRvFs= =Jz8e -END PGP SIGNATURE-
Re: [freenet-dev] New java-based installers
It's OK on Linux, but the installer and the first time wizard don't ask if I want auto-start (and I don't want auto-start). On Fri, May 22, 2009 at 9:08 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: The java-based installer has been updated. Windows users already see the windows installer, this is for mac and linux users. The installer no longer asks about auto-start, plugins or auto-update (all but auto-start are asked in the first-time wizard), start on reboot support on OS/X should be fixed thanks to mrsteveman, and we are shipping the offline installer, with all the dependancies included, except for in the jnlp version used for mac's (this should probably be fixed soon). Both the wininstaller and the java installer are now being distributed via CoralCache, which can achieve good download speeds, but a file cannot be updated easily once it has been published. Because we are bundling all the dependancies in both the windows installer and the java installer, it will need to be rebuilt for every new stable build. If you have a mac, please test the installer. In particular, does Freenet successfully restart after a reboot (it should start up during login). If you don't have a mac, testing would still be helpful. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
On Friday, 22. May 2009 23:10:42 Mike Bush wrote: I have been watching this debate an I was wondering whether it could help to have 2 sets of trust values for each identity in a trust list, this could mean you could mark an identity as spamming or that I don't want to see these posts again as i find them objectionable. This is what Credence did in the end for spam detection on Gnutella, so it might fit the human psyche :) People got the option to say that's bad quality or misleading, I don't like it or that's spam. For messages that could be * that ID posts spam * that ID posts crap The first can easily be reviewed, the second is subjective. That would give a soft group censorship option, but give the useful spam detection to everyone. Best wishes, Arne PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's useful to you nontheless. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why current ui may be improved, and proposed improvements
On Friday, 22. May 2009 23:38:35 Matthew Toseland wrote: Putting the messages only here is a bad idea. Some of these messages are IMPORTANT. What we need to do is: - show the summary on the Browse Freenet page and maybe others - reduce the number of messages by coalescing them and shifting them to the relevant pages: You have 6 messages with a link to the Friends page rather than one for each n2ntm, similar with bookmark updates. I personally like having the messages at the top. freind to friend messages are the major way to keep in contact with your friends, and the friends are important, so their messages should be visible instantly. If a friend says I've been compromised every other user HAS TO see that on the first page. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday, 23. May 2009 02:20:23 Clément wrote: A always seeable (sorry for new words...) button 'Shutdown the node' and 'Restart the node' You want to encourage people to shut down? IMHO the best way to do that is with a system tray icon. Hum, in all application you can always exit the application in one click. I know freenet needs people to run it as long as they can, but hidding the shutdown button is not a solution (we don't want to force them to run freenet, do we ? ;) ) Why not just add a pause button to the ones on the start page? The stop and restart buttons currently are on the first page. But maybe all these options could be moved to a manage your node or maintenance page. Configuration, Statistics and Reachability could also go there. As addition: I think up- and downloads should be called up- and downloads - regardless of how queuey they are :) Then they should also have a download key field like the one on the start page. It could differ from teh one on teh start page by always downloading to the download folder. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday 23 May 2009 01:20:23 Clément wrote: Le vendredi 22 mai 2009 23:38:35, Matthew Toseland a écrit : On Friday 22 May 2009 17:31:46 Clément wrote: Hi all, First, let's see the current situation : #Navigation : 9 items is really the max we can afford. Currently there are 9 items, but they aren't all necessary, and can confuse the newbies. Agreed, we need sub-menus. #Browse Freenet page : The “Search Freenet” field and bookmarks are definitly a good thing. However, why do we have : “Fetch a key” : we don't want to fetch a key, we want to browse Freenet. Some users DO want to fetch a key. But maybe it should be on the queue page. Yep, here I just list the points that I don't find logical. If we want to fetch a key, we go in the downloads page. If we want to visit a site, we need a box to do so (see below, I forgot to put that on the browse page proposition) Okay, so you just want to change the name of the box from Fetch a key (CHK, USK, SSK) ... to what? “Version Information Node Control” : we don't care, we just want to browse Freenet. When they come to us, we usually need to know the version number. Sure, but I don't think it's the right place to put this information. It should be under the status/statistics page, or maybe we can add a submenu status/node info. It is highly unlikely that a newbie will visit the stats page, or remember anything they see there. “Current Activity” : idem Fair point. I have deleted Current Activity. #Messages : I agree we need to inform user when something is wrong. However, for the bookmarks, it's not the good place. I don't think either that there should be one page just for the messages : sometimes there is no message, it just wastes space. In which case we don't show the menu item. Ah, my bad then. But it's not really better, since menu item shouldn't disappear : we need consistency over the time. One thing has exactly one place, and always the same. Okay. It should be under a submenu. If we put all the messages on the main page in full, they take up so much space that newbies don't see the rest of the page. Yep, that's not a solution. There are a number of messages that take up multiple slots on the message list when they should really just post a summary and point to another page where they are in full (e.g. n2ntms should be on the friends page, bookmark updates on the browse freenet page). We should probably either 1) not link the messages page from the main menu, but keep it, or 2) make messages expand themselves when you click on them #Download and Upload : No clear separation between dowloads and uploads. Agreed. WHEN we have sub-menus, we should separate the two. Sub-menu should be easy to implement. Who is going to implement it? I'm not a CSS wizard by any means... Caco_Patane send me a draft that would work with one of the themes, but I don't think it would work with the others. We need to modify all of the themes to support sub-menus. How exactly can be on a per-theme basis, they can be CSS popups or they can be a horizontal menu to go with the existing vertical or they can just be another horizontal menu under a horizontal menu etc. But somebody needs to do the work. Save the HTML from the homepage, modify it to have submenus, modify each CSS so that it works. #Plugins : This is a mess : here we access the plugins, we can add an official plugin, we can add a plugin from an url, we can add a plugin from freenet. It is not very user-friendly, because the box doesn't tell a newbie very much, and the dropdown for official plugins doesn't give any indication what they do. However, the functionality is important. We may want to split this into multiple pages under a sub-menu, but we certainly want to document the official plugins. Yep, see the Configuration/Plugin page. #Connections to friends + connections to strangers : Why 2 separate pages ? Because they are different! Friends and Strangers are completely different IMHO. Friends have names, you can send them text messages, etc. Strangers are just numbers - normal users don't care about their IP address, etc. Hmm, ok. We might want a separate sub-page for messages to/from Friends, or we might want to show more newbie-friendly info for each Friend in a more verbose way rather than a table. Why showing informations about the current activity of the node ? Good question. Some of it is per-node so clearly has to be here (but only in advanced mode), but the status at the top is debatable. It's redondant information yes (I mean the status). Well, we do need the totals, don't we? #Configuration : A big big mess. Really. When in simple mode, it's almost ok, but in advanced mode Please could you elaborate on that a bit? Well, one unique
Re: [freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday 23 May 2009 11:04:12 Arne Babenhauserheide wrote: On Saturday, 23. May 2009 02:20:23 Clément wrote: A always seeable (sorry for new words...) button 'Shutdown the node' and 'Restart the node' You want to encourage people to shut down? IMHO the best way to do that is with a system tray icon. Hum, in all application you can always exit the application in one click. I know freenet needs people to run it as long as they can, but hidding the shutdown button is not a solution (we don't want to force them to run freenet, do we ? ;) ) Why not just add a pause button to the ones on the start page? Because we haven't implemented pause yet? :) But yes, it's a good idea. The stop and restart buttons currently are on the first page. But maybe all these options could be moved to a manage your node or maintenance page. Perhaps, or perhaps we need a status line, which could include simple vs advanced mode, color coded security levels, pause vs un-pause, shutdown, restart, language selector, and a count of non-serious alerts? This would not take up very much space vertically and could probably be manageable horizontally. Configuration, Statistics and Reachability could also go there. Yes, this probably makes sense. As addition: I think up- and downloads should be called up- and downloads - regardless of how queuey they are :) Agreed. Then they should also have a download key field like the one on the start page. It could differ from teh one on teh start page by always downloading to the download folder. Yes. Although we already have Bulk Downloads, and we don't want to get rid of it ... maybe better document it? Bulk Downloads - Download files by key ??? And then on the Browse Freenet page, Fetch a Key (CHK, SSK, USK) - Fetch a freesite by key ??? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
On Saturday 23 May 2009 10:43:09 Arne Babenhauserheide wrote: On Friday, 22. May 2009 23:10:42 Mike Bush wrote: I have been watching this debate an I was wondering whether it could help to have 2 sets of trust values for each identity in a trust list, this could mean you could mark an identity as spamming or that I don't want to see these posts again as i find them objectionable. This is what Credence did in the end for spam detection on Gnutella, so it might fit the human psyche :) People got the option to say that's bad quality or misleading, I don't like it or that's spam. For messages that could be * that ID posts spam * that ID posts crap The first can easily be reviewed, the second is subjective. That would give a soft group censorship option, but give the useful spam detection to everyone. Best wishes, Arne PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's useful to you nontheless. People will game the system, no? If they think paedophiles are scum who should not be allowed to speak, and they realise that clicking This is spam is more effective than This is crap, they will click the former, no? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] ITA l10n update 090523
updated to r23771
please commit
BookmarkEditorToadlet.invalidName=Il nome del segnalibro non é valido
BookmarkEditorToadlet.invalidNameTitle=Nome Non Vaildo
ConfigToadlet.returnToNodeConfig=Torna alla pagina della configurazione
FNPPacketMangler.somePeersDisconnectedStillNotAckedDetail=Probabile bug:
mancata conferma di avvenuta ricezione p[acchetti da parte di n. ${count} peer,
possibilmente a causa di un 'bug' (difetto) nel programma. Si prega di
riportare l'accaduto presso il bug tracker
${link}https://bugs.freenetproject.org/${/link} o e-mail
supp...@freenetproject.org. Includere questo messaggio e la versione di Freenet
che si sta usando. NON é necessario includere l'indirizzo IP dei peer affetti
(specialmente nel caso di peer darknet). IP dei peer disconnessi:
FProxyToadlet.blocksDetail=Blocchi: ${fetched} / ${required} (totale ${total}
falliti ${failed} falliti in modo permanente ${fatallyfailed})
FProxyToadlet.contentTypeLabel=Tipo di contenuto:
FProxyToadlet.fetchingPageBox=Download della pagina richiesta in corso
FProxyToadlet.fetchingPageOptions=Opzioni disponibili
FProxyToadlet.fetchingPageTitle=E' in corso il download di una pagina
FProxyToadlet.progressCheckingStore=Ricerca del file o pagina nella cache
locale in corso. Se la ricerca nella cache locale non produrrà risultati, si
procederà al download da Freenet.
FProxyToadlet.progressDownloading=Download da Freenet in corso. L'operazione
potrebbe avere una durata compresa tra i pochi secondi ed alcuni minuti a
seconda del numero di richieste per quella pagina o file: un file che viene
molto richiesto diviene più facile e veloce da scaricare.
FProxyToadlet.progressNotFinalized=E' possibile che l'indicatore di progresso
(progress bar) salti avanti e indietro a causa del numero insufficiente di
blocchi scaricati finora che rende poco attendibili le informazioni relative
alle dimensioni del file.
FProxyToadlet.progressOptionZero=E' possibile attendere che il download della
pagina richiesta giunga a completamento. Questa pagina temporanea verrÃ
aggiornata automaticamente ogni 2 secondi fino al completamento o fallimento
del download. In alternativa:
FProxyToadlet.timeElapsedLabel=Tempo trascorso:
FirstTimeWizardToadlet.autoUpdate=Aggiornamenti Automatici
FirstTimeWizardToadlet.autoUpdateAutodeploy=Aggiorna Freenet automaticamente
FirstTimeWizardToadlet.autoUpdateLong=E' possibile configurare Freenet per
auto-aggiornarsi automaticamente. Scelte disponibili:
FirstTimeWizardToadlet.autoUpdateNoAutodeploy=Notifica quando è disponibile
una nuova versione
FirstTimeWizardToadlet.autodetectedSuggestedLimit=Scelta consigliata:
FirstTimeWizardToadlet.bandwidthLimitAfter=Si prega di tenere presente che il
nodo Freenet resterà sempre attivo ed utilizzerà tutta la banda configurata
in questa pagina (fino a 50-100KB/sec all'incirca). Se il contratto con il
vostro ISP (Internet Service Provider) prevede un massimo mensile di
trasferimento dati, è opportuno tenere in considerazione tale limite al
momento di decidere quanta banda assegnare a Freenet. La banda configurata in
questa pagina si riferisce all' upload; l'uso di banda in download sarà più o
meno equivalente.
FirstTimeWizardToadlet.clickContinue=Continua
FirstTimeWizardToadlet.congratz=Benvenuti a bordo!
FirstTimeWizardToadlet.enableJSTUN=Abilita il rilevamento automatico
dell'indirizzo IP con JSTUN. Il servizio si svvale di server centralizzati per
determinare l'indirizzo IP dell'utente (come fanno, per esempio, i programmi di
telefonia internet). Disabilitare se ciò può rappresentare un problema.
FirstTimeWizardToadlet.enableUPnP=Abilita Plug and Play Universale (UPnP). Da
utilizzare se la home LAN comprende un router. Non utilizzare in caso di
connessione diretta a ISP via block-ethernet, o in presenza di persone non
affiabili sulla rete locale.
FirstTimeWizardToadlet.plugins=Plug-in
FirstTimeWizardToadlet.pluginsLong=I plug-in sono estensioni opzionali che
aggiungono diverse funzionalità a Freenet, ma alcuni di essi poaaono
presentare problemi di sicurezza per alcuni utenti (vedi sotto)
FirstTimeWizardToadlet.stepMiscTitle=Configurazione Automatica di Freenet:
Aggiornamenti e Plug-in
NodeClientCore.alwaysCommit=Scrivi su disco dopo ogni attività su database?
NodeClientCore.alwaysCommitLong=Se impostato su 'falso', i dati vengono scritti
su disco ogni 30 secondi. Impostando su 'vero', saranno scritti dopo ogni
cambiamento nel database. Se da un lato ciò causerà una riduzione nelle
prestazioni, il vantaggio è che si eliminerà il rischio di perdere dei dati
in caso di arresto improvviso. L'uso di memoria risulterà inoltre leggermente
inferiore. In casi normali questa opzione dovrebbe essere impostata su 'falso'
per ridurre l'accesso al disco.
PluginManager.officialPluginLoadFailedTryAgain=Carica la versione più recente
dal server del Progetto Freenet (NON ANONIMO)
QueueToadlet.failedToRemoveAll=Rimozione di tutte le richieste fallita.
[freenet-dev] Some French translations
Some French translations. freenet.l10n.fr.override.properties Description: Binary data ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
On Sat, May 23, 2009 at 10:10 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: We want to make it easy, or nobody will do it. Poring over your trust list day after day is not most people's idea of fun. There are three approaches, given positive trust only. Depending on the level of effort exerted by the spammer, we move from one tradeoff between spam resistance and censorship resistance to the next. IMHO the last stage involves significant risk of censorship or at least collateral damage, while obviously having the strongest spam resistance. The first approach is to mark spammers as spammers, and limit the capacity of trusted identities to create new spammers by for example limits on the number of identities that can change in a trust list in one day. This means that everyone will have to mark all the spam identities as spam, much as in Frost with the Alice bot. It will deter newbies, but it should be usable for the determined. Note that it is *essential* on a positive trust only network that our spam markings override others' positive trust levels. The second approach is when we mark an identity as spam, WoT realises that an identity trusting that spammer also trusts a lot of other spammers, and proposes that we mark the parent identity as a spammer, at least for purposes of trust list trust. Hopefully this will be enough. The cost for every user will be to mark a few spammer posts as spam, and then accept WoT's recommendation to mark the parent as spammer. A few will be an arbitrary parameter that will have to be argued about, higher means less chance of marking non-spammers as spammers, but at the cost of seeing more spam. The third approach is that when we mark the parent identity as spam, WoT suggests marking those who trust the parent identity also as spammers for purposes of trust list trust (if we trust them; if we don't, it's not our problem; we are trying to optimise the network *for other people*, particularly for newbies, here). We can try to be polite about this using ultimatums, since it's likely that they didn't deliberately choose to trust the spam-parent knowing he is a spam-parent - but if they don't respond in some period by removing him from their trust list, we will have to reduce our trust in them. This will cause collateral damage and may be abused for censorship which might be even more dangerous than the current problems on FMS. However, if there is a LOT of spam, or if we want the network to be fairly spam-free for newbies, the first two options are insufficient. :| I'm not certain you're correct about this. The first two methods are, imho, sufficient to limit spam to levels that are annoying, but where the network is still usable. Even if they download a bunch of messages, a new user only has to click the spam button once per spamming identity, and those are limited in a well defined manner (linear with modest coefficient with the number of dummy identities the spammer is willing to maintain). My suspicion is that if all they can aspire to be is a nuisance, the spammers won't be nearly as interested. There is much more appeal to being able to DoS a board or the whole network than being able to mildly annoy the users. So if we limit the amount of damage they can do to a sane level, the actual amount of damage done will be noticeably less than that limit. Can we agree that we should implement the second option in WoT then? Yes, though I think it should default to only alerting the user in the case of relatively obvious abuse. As part of that I think it should give the identity in question a modest grace period to correct its trust list (if trust lists are published daily, 2 days seems appropriate). Given the churn rate limits, I don't think that's an issue. There is another possible optimization we could do (I've just thought of it, and I'm not entirely certain that it works or that I like it). Suppose that Alice trusts Bob trusts Carol (legitimate but confused) trusts Sam (a spammer), and Alice is busy computing her trust list. Bob has (correctly) marked Sam as a spammer. In the basic implementation, Alice will accept Sam. Bob may think that Carol is normally correct (and not malicious), and be unwilling to zero out his trust list trust for her. However, since this is a flow computation, we can place an added restriction: when Alice calculates trust, flow passing through Bob may not arrive at Sam even if there are intermediate nodes. If Alice can find an alternate route for flow to go from Alice to Carol or Sam, she will accept Sam. This modification is in some ways a negative trust feature, since Bob's marking of Sam as a spammer is different from silence. However, it doesn't let Bob censor anyone he couldn't censor by removing Carol from his trust list. Under no circumstances will Alice using Bob's trust list
Re: [freenet-dev] Why WoTs won't work....
On Friday 22 May 2009 22:38:43 Evan Daniel wrote: On Fri, May 22, 2009 at 5:03 PM, Matthew Toseland t...@amphibian.dyndns.org wrote: - Making CAPTCHA announcement provide some form of short-lived trust, so if the newly introduced identity doesn't get some trust it goes away. This may also be implemented. This would require adding trust to new people, As you can see with FMS, having everyone spending dayly time on trustlist adjustments is just an idea, which wont come true. So this would mean that every identity that is not very active will loose any trust and would have to introduce himself again. More pain and work resulting in less users. See my proposal (other mail in this thread, also discussed previously). Short-range but long-lived trust is a better substitute, imho. I would call it censorship because those that see you because of captcha announcement can themselves say what happens, -if they dont give you trust, most wont see you = you are lost, are censored -if the give you trust, everyone will see you = not censored This would give a small group of people the chance to censor newly announced identities (also the group may be different for every identity). Then use a more permissive capacity:distance function. There is no requirement that you use a shorter range function, or that you use the same function as everyone else. IMHO, the default should be somewhat shorter range, in an attempt to balance the number of people that see new identities. As you observe, too few leads to censorship possibilities (out of malice or just plain laziness). Too many means that an identity with CAPTCHA trust only can spam and have everyone see that spam, which provides the spammer a reasonably efficient way to send spam. So it's a tradeoff which can be easily configured by the user. Yes. As always, intelligent defaults are important; they should be applicable to most newbies, but don't need to meet everyone's needs. And if you change it unwisely, you hurt only yourself (other people don't even notice). I agree with pretty much all of the above, but the medium-term worry is that we will start to have to worry about those who trust spammers, and those who trust those who trust spammers. By eliminating negative trust, Advogato forces us to either tolerate a certain (and unclear) amount of spam, or spend a lot of effort on hunting down those who trust spammers, resulting in massive collateral damage. Also, what do you mean by review of identities added from others? Surely you don't mean that I should have to manually review every poster? Isn't the whole point of using a wot in the first place that I can get good trust estimates of people I've never seen before? In FMS, there is currently a simple page, where the latest added identities are listed and how they where listed. So if you get many spamming identities and they are all added from 1 trusted peer, just remove his trustlist trust and all those new spamming identities wont reach you. We want to make it easy, or nobody will do it. Poring over your trust list day after day is not most people's idea of fun. There are three approaches, given positive trust only. Depending on the level of effort exerted by the spammer, we move from one tradeoff between spam resistance and censorship resistance to the next. IMHO the last stage involves significant risk of censorship or at least collateral damage, while obviously having the strongest spam resistance. The first approach is to mark spammers as spammers, and limit the capacity of trusted identities to create new spammers by for example limits on the number of identities that can change in a trust list in one day. This means that everyone will have to mark all the spam identities as spam, much as in Frost with the Alice bot. It will deter newbies, but it should be usable for the determined. Note that it is *essential* on a positive trust only network that our spam markings override others' positive trust levels. The second approach is when we mark an identity as spam, WoT realises that an identity trusting that spammer also trusts a lot of other spammers, and proposes that we mark the parent identity as a spammer, at least for purposes of trust list trust. Hopefully this will be enough. The cost for every user will be to mark a few spammer posts as spam, and then accept WoT's recommendation to mark the parent as spammer. A few will be an arbitrary parameter that will have to be argued about, higher means less chance of marking non-spammers as spammers, but at the cost of seeing more spam. The third approach is that when we mark the parent identity as spam, WoT suggests marking those who trust the parent identity also as spammers for purposes of trust list
Re: [freenet-dev] Why current ui may be improved, and proposed improvements
On Saturday 23 May 2009 10:48:18 Arne Babenhauserheide wrote: On Friday, 22. May 2009 23:38:35 Matthew Toseland wrote: Putting the messages only here is a bad idea. Some of these messages are IMPORTANT. What we need to do is: - show the summary on the Browse Freenet page and maybe others - reduce the number of messages by coalescing them and shifting them to the relevant pages: You have 6 messages with a link to the Friends page rather than one for each n2ntm, similar with bookmark updates. I personally like having the messages at the top. freind to friend messages are the major way to keep in contact with your friends, and the friends are important, so their messages should be visible instantly. If a friend says I've been compromised every other user HAS TO see that on the first page. Well, no other alert is shown in full at the moment. Isn't it better to just say You have 5 messages from friends ? Or You have 1 new messages from friends ? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
On Sat, 2009-05-23 at 15:06 +0100, Matthew Toseland wrote: On Saturday 23 May 2009 10:43:09 Arne Babenhauserheide wrote: On Friday, 22. May 2009 23:10:42 Mike Bush wrote: I have been watching this debate an I was wondering whether it could help to have 2 sets of trust values for each identity in a trust list, this could mean you could mark an identity as spamming or that I don't want to see these posts again as i find them objectionable. This is what Credence did in the end for spam detection on Gnutella, so it might fit the human psyche :) People got the option to say that's bad quality or misleading, I don't like it or that's spam. For messages that could be * that ID posts spam * that ID posts crap The first can easily be reviewed, the second is subjective. That would give a soft group censorship option, but give the useful spam detection to everyone. Best wishes, Arne PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's useful to you nontheless. People will game the system, no? If they think paedophiles are scum who should not be allowed to speak, and they realise that clicking This is spam is more effective than This is crap, they will click the former, no? Yes but offering this could separate those who wish to mark what they are objected to and don't wish to see from those who wish to censor other peoples views of the service against their will. I don't think the first group should be a problem if they have this option. Surely it depends on what proportion are in each group, I've not used FMS, maybe someone who uses it has some idea whether these groups exist. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] ITA l10n update 090523
On Saturday 23 May 2009 16:22:16 Luke771 wrote: updated to r23771 please commit Pushed to git. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Some French translations
On Saturday 23 May 2009 17:02:47 3BUIb3S50i 3BUIb3S50i wrote: Some French translations. Pushed to git. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
On Sat, May 23, 2009 at 10:06 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Saturday 23 May 2009 10:43:09 Arne Babenhauserheide wrote: On Friday, 22. May 2009 23:10:42 Mike Bush wrote: I have been watching this debate an I was wondering whether it could help to have 2 sets of trust values for each identity in a trust list, this could mean you could mark an identity as spamming or that I don't want to see these posts again as i find them objectionable. This is what Credence did in the end for spam detection on Gnutella, so it might fit the human psyche :) People got the option to say that's bad quality or misleading, I don't like it or that's spam. For messages that could be * that ID posts spam * that ID posts crap The first can easily be reviewed, the second is subjective. That would give a soft group censorship option, but give the useful spam detection to everyone. Best wishes, Arne PS: Yes, I mostly just tried to clarify Mikes post for me. I hope the mail's useful to you nontheless. People will game the system, no? If they think paedophiles are scum who should not be allowed to speak, and they realise that clicking This is spam is more effective than This is crap, they will click the former, no? I would assume that's the normal case. OTOH, there isn't much harm in implementing it, and if some people use it, that would help somewhat... Perhaps implement, but not required for initial release? Evan Daniel ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Where to put GWT?
sashee is working on making the web interface more dynamic. Google Web Toolkit will be used to translate some java code into javascript, and then this generated javascript will be built into Freenet in much the same way as themes are. The problem is that we need to be able to rebuild it when somebody does an ant distclean, e.g. when creating a signed jar to distribute as a stable build. IMHO the best option is to put GWT, in source code form, without the platform speciifc stuff (apparently we only need two jars to compile java into javascript, they add up to 15MB), into the contrib repository, thus keeping the fred repo clean. There is already a lot of third party code in the contrib repository, and it is quite large, so IMHO this is not a problem. Then when you do ant distclean in fred, it will wipe the generated javascript, and then when you run ant, it will rebuild it. If contrib is not unpacked in ../contrib then the build will fail. Another option would be to include the compiled jars in contrib (bad if you want to do a full rebuild), or to just require GWT to be unpacked in ../gwt . Any objections to my proposal, or support for other options? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Where to put GWT?
* Matthew Toseland t...@amphibian.dyndns.org [2009-05-23 20:43:56]: sashee is working on making the web interface more dynamic. Google Web Toolkit will be used to translate some java code into javascript, and then this generated javascript will be built into Freenet in much the same way as themes are. The problem is that we need to be able to rebuild it when somebody does an ant distclean, e.g. when creating a signed jar to distribute as a stable build. IMHO the best option is to put GWT, in source code form, without the platform speciifc stuff (apparently we only need two jars to compile java into javascript, they add up to 15MB), into the contrib repository, thus keeping the fred repo clean. There is already a lot of third party code in the contrib repository, and it is quite large, so IMHO this is not a problem. Then when you do ant distclean in fred, it will wipe the generated javascript, and then when you run ant, it will rebuild it. If contrib is not unpacked in ../contrib then the build will fail. Another option would be to include the compiled jars in contrib (bad if you want to do a full rebuild), or to just require GWT to be unpacked in ../gwt . Any objections to my proposal, or support for other options? Make ant download the appropriate version of GWT if needed. That's what we use to do with the wrapper and other dependancies. NextGen$ signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
On Saturday, 23. May 2009 16:06:51 Matthew Toseland wrote: People will game the system, no? If they think paedophiles are scum who should not be allowed to speak, and they realise that clicking This is spam is more effective than This is crap, they will click the former, no? Not if the penalty for marking something falsely as spam is to lose all trust for their own messages (You falsely reported spam - you're a spammer) while the penalty for thinking different is simply that their ratings won't be taken as seriously. (I hope the above is possible in the implementation). Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
