[freenet-dev] XMLLibrarian binary on downloads.freenetproject.org
XMLLibrarian on downloads.freenetproject.org was compiled with Java 6 and emitting UnsupportedClassVersionError. Please recompile it with Java 5 and update the binary.
[freenet-dev] Using standard ports of encrypted protocols
Arne Babenhauserheide wrote: > On Wednesday, 20. May 2009 18:14:53 Matthew Toseland wrote: >> Depends on your threat model. Freenet traffic clearly doesn't look like >> these without proper stego transport plugins, and the connections between >> nodes definitely don't look like them, unless what you are imitating is >> purely peer to peer, in which case you need to look at the other nodes' >> connections as well and/or the timing. > > Is a steganography transport plugin planned? > Yes, but that's long term stuff. The important bit is the plugin system. Stego transports shouldn't be bundled by default otherwise they become part of the protocol and that defeats the purpose. NextGen$
[freenet-dev] Usability test results
On Friday 15 May 2009 17:05:09 Robert Hailey wrote: > > On May 14, 2009, at 5:06 PM, Matthew Toseland wrote: > > > On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: > >> > >> On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: > >> > >>> Because we were both on the same LAN, it did not connect, until I > >>> told him to > >>> set it to allow local addresses on that peer. There should be a > >>> checkbox when > >>> adding a noderef, defaulting to on, "Friend may be on the same local > >>> network > >>> as me" or something. (#3098) > >> > >> I think that it should be possible to automatically detect this. > >> Specifically, if we detect that our peer has the same "external > >> address" as us, try and connect locally. Is that a reliable > >> indicator? > > > > Not very (what if it changes?) ... we don't want darknet peers to > > cause us to > > connect to addresses on our LAN ... otherwise the solution is simply > > to try > > the local addresses included ... > > I agree that we don't want to try the local addresses of ~all~ our > peers; local connections are in principal an exception and not cause > enough to be sending so much local garbage handshaking traffic (that > could give away a freenet node). > > But I think this is the right way to go... If it is not defined for a > given peer (allow/disallow local connections), then we could just > calculate the default boolean as > his.extAddresses.containsAny(my.extAddresses) if it matches, then > there is an excellent chance of it being a local connection (99%). If > it changes, that's great! The decision to try local connections would > change too! As it's probably a laptop that has floated out of the LAN > (and we would want to stop sending handshakes to the local address > anyway). At worst we might send a few garbage handshakes to local non- > freenet machine until we connect to the node & find it's new external > address. > > The reason I think this would solve the problem because (I think) the > principal reason that the nodes could not communicate is because the > gateway would have to send a packet to itself (many inexpensive or > firewalled ones will not). > > e.g. > internal -> firewall -> external (generally works w/ current > countermeasures) > > internal --> > firewall > internal <-- > > Does not work (at least for me). So what I propose is really an > extension of "detecting the problem" (the gateway which has the same > external ip). Don't know about multihoming, but I presume that this is > works in the common case. Nonetheless it is highly unreliable as a way to detect it with dynamic external IP address, especially given that the two nodes are unable to communicate by any other means. -- 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/20090521/750183d2/attachment.pgp>
[freenet-dev] XMLLibrarian binary on downloads.freenetproject.org
On Thu, May 21, 2009 at 5:23 PM, Matthew Toseland wrote: > On Thursday 21 May 2009 03:53:04 you wrote: >> XMLLibrarian on downloads.freenetproject.org was compiled with Java 6 >> and emitting UnsupportedClassVersionError. >> Please recompile it with Java 5 and update the binary. >> > It was compiled with your plugin build script iirc. Please update the build > script for all the plugins to use java 5. I have just updated with target="1.5" at 222d686 HOWEVER, you should always build with a 1.5 JDK. This is the only way to ensure it does not use any Java 6 specific API (accidentially). --
[freenet-dev] Usability test results
queue rather than actually > sending a packet. But it looks to me like a bit of cruft from a > previous design. > > In any case, you have a design note in the comments of PacketThrottle > that it would be better to have a sorted list or red/black tree rather > than a ticket system (where all threads wakeup); maybe a new class > needs to be written (BulkQueue) that *only* interleaves waiters (round > robin?) and the packet throttle then used only for actually sending > packets. Yeah... -- 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/20090521/fe53d0b2/attachment.pgp>
[freenet-dev] Separate browser or not
Matthew Toseland skrev: > On Sunday 17 May 2009 11:43:26 Zero3 wrote: >> Colin Davis skrev: >>> As implemented currently, Private browsing is all-or-nothing in >>> FF3.5beta4 and Safari, but Google Chrome is per-window. Firefox has issues with coalescing windows, no? If I run firefox with > command line options to use one profile, it may use another if a window is > already open, there are things like that... Is opening a window with privacy mode enabled safe and reliable? >> I guess both ways should work fine for us? We simply launch the browser >> with the command line arguments, and let the browser handle the >> window/tab management? > > No, Firefox might very well end up opening a window in non-incognito mode. Surely such bug would be fixed before the beta turns into final? - Zero3
[freenet-dev] Updating helper executables on Windows
Matthew Toseland skrev: > On Sunday 17 May 2009 11:41:00 Zero3 wrote: >> Matthew Toseland skrev: Detecting the version of an installed application in the launcher (at least in Windows) shouldn't be a problem. It will most likely be registered in the registry next to the .exe path we are checking already for the individual browsers. We can also check the version info of .exes as an alternative (most Windows applications are compiled with various static info like version and author). The Windows launcher is already running Chrome with a command line argument making it start in privacy mode btw. >>> You should prioritise Chrome with privacy mode over Firefox without it. >> Agreed: https://bugs.freenetproject.org/view.php?id=3118. > > I thought you had already done this? At time of writing, no. But since then I managed to figure git out and changed it (hence the bug is now "resolved"). ... which leads to another thing to consider: We need to make it possible to update the start.exe/stop.exe/freenetlauncher.exe files for existing users when new updates are made available. The easiest way to do this right now would probably be to add them to the update.cmd script. - Zero3
[freenet-dev] Freenet 0.7 build 1210
Freenet 0.7 build 1210 is out. Sorry for the delay in announcing it. It will be mandatory at midnight. There was also a minor git mess relating to tagging - it was released from a local branch because I forgot to push before tagging, although it has been merged back into master now. If you are building from source you need to either clone the tag or do "git fetch -t origin" to fetch orphan tags. Changes: - Startup fix: you can now move the persistent temp directory, as long as you update freenet.ini accordingly. This is also an issue when moving the node. - Startup fix: Deleting the persistent temp dir and moving the node failed to startup - Let the node start up even if the database is unrecoverably corrupted. Tell the user what the situation is, and refuse to do any persistent requests or inserts. - Don't commit every database job immediately, unless we need to for memory reasons (some job types), for UI reasons (e.g. starting a request), every 30 seconds, or after every job if the new alwaysCommit config option is enabled. This should reduce disk I/O and improve performance significantly on some systems with big queues. - Fix various client layer bugs, in freesite inserts and other things. - SSK insert collision handling fix - store the data as well as forwarding it. - Minor crypto optimisation in handling SSKs. - First time wizard: remove the memory limit selection page, add a page to ask the user whether to auto-update Freenet and whether to load JSTUN and UPnP (this may reduce performance on a new node *slightly*, but we don't want to have to ask in the installer), warn the user about monthly bandwidth usage, always show the bandwidth and store size pages, minor fixes. - Enable javascript support by default in fproxy, minor fixes, get rid of the MIME type column on the queue page in simple mode, more tolerant parsing of noderefs and bulk download lists. - Fix various connection level bugs, which hopefully once everyone has 1210 will fix the forced disconnected because not acknowledging packets bug. In simulation this fixes "Unmatchable packet from ", which really shouldn't happen! - Minor plugin code improvements (new APIs, require XMLLibrarian version 22). - Internal bugfix which hopefully only was breaking IPv6 address detection from peers. - Internal bugfix relating to moving files, might have caused bugs in several places. - Don't let default changes override the local option for whether to preallocate the store. - Lots of internal cleanup and some work on the many-nodes-one-VM simulators / automated network tests, including a new long-term data retrievability test. Also, the XMLLibrarian plugin now shows a search's progress without using javascript, and immediately from typing a search on the homepage (thanks mikeb). KeyExplorer 0.4 beta is out, and there has been more work on the WoT web of trust plugin (thanks saces). A bugfix in the UPnP plugin, and as previously mentioned we deployed the new windows installer (thanks Zero3). Thanks to: sdiz 3BUIb3S50i platy nextgens saces juiceman -- 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/20090521/5e0d16f6/attachment.pgp>
[freenet-dev] Plugin snapshots
Please post on the list when you want me to distribute a new snapshot of a plugin. Thanks. -- 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/20090521/a0f82bca/attachment.pgp>
[freenet-dev] Updating helper executables on Windows
On Thu, May 21, 2009 at 6:58 AM, Zero3 wrote: > Matthew Toseland skrev: >> On Sunday 17 May 2009 11:41:00 Zero3 wrote: >>> Matthew Toseland skrev: > Detecting the version of an installed application in the launcher (at > least in Windows) shouldn't be a problem. It will most likely be > registered in the registry next to the .exe path we are checking already > for the individual browsers. We can also check the version info of .exes > as an alternative (most Windows applications are compiled with various > static info like version and author). The Windows launcher is already > running Chrome with a command line argument making it start in privacy > mode btw. You should prioritise Chrome with privacy mode over Firefox without it. >>> Agreed: https://bugs.freenetproject.org/view.php?id=3118. >> >> I thought you had already done this? > > At time of writing, no. But since then I managed to figure git out and > changed it (hence the bug is now "resolved"). > > ... which leads to another thing to consider: We need to make it > possible to update the start.exe/stop.exe/freenetlauncher.exe files for > existing users when new updates are made available. > > The easiest way to do this right now would probably be to add them to > the update.cmd script. > > - Zero3 > ___ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > I would be happy to do this, however I will need a defined directory structure on the download site, with known file names. Like we have the .url link for the freenet.jar. I believe I can use the .sha1 file to check for updates if you want to have a static name. ie wrapper_win32x86.exe etc. Also I would prefer to not have them inside a zip unless we have have a built-in unzipping program in Windows I can reliably call by command line. Otherwise we will have to bundle yet another third party utility.
[freenet-dev] Separate browser or not
As an aside, Matthew had asked in the past about reducing the number of connections from the browser to the node. Digg's new library may be able to assist- It breaks images into data uris, and then inlines them. Even if Freenet doesn't want to use the library, inlining images as Data URIs may improve load times. Just a thought. -CPD http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype
[freenet-dev] Updating helper executables on Windows
On May 21, 2009, at 11:32 AM, Juiceman wrote: > On Thu, May 21, 2009 at 6:58 AM, Zero3 > wrote: >> Matthew Toseland skrev: >>> On Sunday 17 May 2009 11:41:00 Zero3 wrote: Matthew Toseland skrev: >> Detecting the version of an installed application in the >> launcher (at >> least in Windows) shouldn't be a problem. It will most likely be >> registered in the registry next to the .exe path we are >> checking already >> for the individual browsers. We can also check the version info >> of .exes >> as an alternative (most Windows applications are compiled with >> various >> static info like version and author). The Windows launcher is >> already >> running Chrome with a command line argument making it start in >> privacy >> mode btw. > You should prioritise Chrome with privacy mode over Firefox > without it. Agreed: https://bugs.freenetproject.org/view.php?id=3118. >>> >>> I thought you had already done this? >> >> At time of writing, no. But since then I managed to figure git out >> and >> changed it (hence the bug is now "resolved"). >> >> ... which leads to another thing to consider: We need to make it >> possible to update the start.exe/stop.exe/freenetlauncher.exe files >> for >> existing users when new updates are made available. >> >> The easiest way to do this right now would probably be to add them to >> the update.cmd script. >> >> - Zero3 >> > > I would be happy to do this, however I will need a defined directory > structure on the download site, with known file names. Like we have > the .url link for the freenet.jar. I believe I can use the .sha1 file > to check for updates if you want to have a static name. ie > wrapper_win32x86.exe etc. Also I would prefer to not have them inside > a zip unless we have have a built-in unzipping program in Windows I > can reliably call by command line. Otherwise we will have to bundle > yet another third party utility. If it helps, my understanding is that zip & jar are cross compatible. Or more specifically, that a jar is a zip file with extra flags and a manifest file. -- Robert Hailey
[freenet-dev] Separate browser or not
On Thursday 21 May 2009 18:54:38 Colin Davis wrote: > As an aside, Matthew had asked in the past about reducing the number of > connections from the browser to the node. > > Digg's new library may be able to assist- It breaks images into data uris, > and then inlines them. > > Even if Freenet doesn't want to use the library, inlining images as Data > URIs may improve load times. Just a thought. > -CPD Well it's not the stuff that we have already fetched that slows things down, it's the images we have to wait for. > > http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype -- 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/20090521/0d038b3c/attachment.pgp>
[freenet-dev] Separate browser or not
On Thursday 21 May 2009 11:54:32 Zero3 wrote: > Matthew Toseland skrev: > > On Sunday 17 May 2009 11:43:26 Zero3 wrote: > >> Colin Davis skrev: > >>> As implemented currently, Private browsing is all-or-nothing in > >>> FF3.5beta4 and Safari, but Google Chrome is per-window. > >>>> Firefox has issues with coalescing windows, no? If I run firefox with > > command > >>>> line options to use one profile, it may use another if a window is > > already > >>>> open, there are things like that... Is opening a window with privacy mode > >>>> enabled safe and reliable? > >> I guess both ways should work fine for us? We simply launch the browser > >> with the command line arguments, and let the browser handle the > >> window/tab management? > > > > No, Firefox might very well end up opening a window in non-incognito mode. > > Surely such bug would be fixed before the beta turns into final? I have no idea, but it does exactly the above with profiles sometimes iirc. -- 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/20090521/44d7dda6/attachment.pgp>
[freenet-dev] update.cmd in java-based installer
Are all the changes made to update.cmd compatible with the java-based installer? For example, juiceman removed a bunch of commands relating to start.cmd; certainly I haven't tested my changes with the java-based installer. Also, do we want to get rid of Windows support from the java-based installer? The website always shows the exe for windows users now... Oh, and you didn't write version 3.0 - at least not all of it. :) -- 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/20090521/5dc569e9/attachment.pgp>
[freenet-dev] update.cmd in java-based installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, May 21, 2009 at 4:19 PM, Matthew Toseland wrote: > Are all the changes made to update.cmd compatible with the java-based > installer? For example, juiceman removed a bunch of commands relating to > start.cmd; certainly I haven't tested my changes with the java-based > installer. I've always coded it assuming it would be used for both installers, so unless there is a bug, yes. =) I would prefer that there is only one update.cmd on the website. > > Also, do we want to get rid of Windows support from the java-based installer? > The website always shows the exe for windows users now... Hmm. The new installer is nice... Have we received any reports of it not working? I don't see any reason to remove support unnecessarily... It is not much work to copy updates to both branches. > > Oh, and you didn't write version 3.0 - at least not all of it. :) I'll just change it to read "contributions by Juiceman" on next commit. =) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAkoWAZAACgkQ4esu1mlKOs8g5QCfS3h76lE+dBmZLeLTp30ArgRR I+gAnjYsuPWByBr9atZO6K4+rBjxt0l1 =Rsmn -END PGP SIGNATURE-
[freenet-dev] Why WoTs won't work....
It's not all that interesting. It has been discussed to death many times. The Advogato algorithm (or something like it) solves this problem (not perfectly, but far, far better than the current FMS / WoT alchemy), as I have explained in great detail. Evan Daniel On Sat, May 9, 2009 at 12:57 PM, wrote: > Interesting discussion from Frost, especially the last post at the bottom. > Its about WoTs in general and why they won't work. > > > > - Hahahahah at YLE3ZHs5LkiwE3FdJyQlcF5+RkA - 2009.04.05 - 02:28:11GMT > - > > I had to forward this one here. > > --- jezreel?X~GLTTHo9aaYtIpGT6OOyBMMFwl3b8LwFu6TUw9Q82E sent via FMS on > 2009-04-05 at 01:31:54GMT --- > > Probably not an amazing subject, but FMS is so dead lately so what the > hell. ?Falafel, why do some of the folks posting to Frost hate you so > much? ?In particular Luke771 and VolodyA. ?You generally seem like a > nice identity so I'm just curious. > -- > jezreel at > pbxwgrdegrigwuteoz3tc6cfla2xu3trmi2tgr2enfrvi4bxkzlectshfvyw2wcxkrffslccijku4z2om5gtoojrpzdfcolkovtdawjuifigkrcqjbevsvrnla2xotcdpfvw6lkmkzzsyqkrifbucqkf.freemail > > ;)) > > - VolodyA! V A at r0pa7z7JA1hAf2xtTt7AKLRe+yw - 2009.04.11 - > 12:11:26GMT - > > I should point out i do not hate falafel, i do not know him. I do hate what > he is doing to Freenet, however. If he was to stop supporting intruduction of > censorship on Freenet i would not say anything bad about him. > > In fact i tend to agree with much of what he has to say on other subjects. > > -- > May all the sentient beings benefit from our conversation. > > - Denminkan at DlKKAIKia79j4oVPbgFK4zNh25Y - 2009.04.14 - 16:13:07GMT > - > > Falafel is doing nothing. If a single guy can make the protocol not work, > then the protocol is shitty from the start and we need to write a new one. > > - Anonymous - 2009.04.14 - 20:46:59GMT - > > The only shit around here is spewing from the mouths of those who don't > understand how it works. ?No one can stop you from seeing what you want to > see. ?Anyone who tells you otherwise is spreading misinformation. > > - Luke771 at CH4jCmDc27eeqm9Cw_WvJu+COIM - 2009.05.04 - 01:01:46GMT > - > > > No one can really censor FMS alright, BUT there IS a problem with those > 'censored trust lists' anyway. > The existance of censored trust lists forces users to actively maintain their > own trust lists, the WoT wont work 'on its own' as it would if everyone used > it the way it's supposed to. > > Let me try to explain: if everyone used wot to block flood attacks and > nothing else, new users wouldnt need to try and find out which trust lists > are 'good', they wouldnt need to work on thir trust lists for hours every > day, try to spot censors or "guys who wont block pedos", they could simply > use FMS and occasianlly set a high trust for someone they actually trust, or > lower the trust for someone they caught spamming > > But the current situation makes FMS a pain in the ass. Users have to work on > your trust lists regularly, and new users risk (and probably do) to have some > of the content blocked by some censor because the guy posted one message on a > board that the censor found 'immoral'. > > It may take time until the new user figures out which trust lists to use, and > there's a very real risk that he would think that it isnt worth the hassle > and give up on FMS completely. > I did that, others did that, and more will. > > THAT is the real problem with the Little Brothers, not their non-existent > ability to censor content. they cant censor anything and they know it. But > they can and do make FMS a pain in the ass to use. > > Another problem is that, assuming that the fms community will survive (which > i dontthink it will), it my end up split into a number of closed > sub-communities that refuse to talk to each other. But this is only a guess, > so far. We'll have to see how it turns out. > > In the meantime, making FMS into a PITa has been done already, that is why > FMS is as good as dead, and that's why I think that invesiting develpers' > time and effort into WoT and Freetalk is a huge waste: FMS failed because of > human stupidity and arrogance, and so will Freetalk/WoT, and I really cant > understand why the devs cant see the obvious (or refuse to admit it) > > BTW, I dont hate Falafel. Hate costs energy. A lot of it. > -- > FAFS - the Freenet Applications FreeSite > USK at > ugb~uuscsidMI-Ze8laZe~o3BUIb3S50i25RIwDH99M,9T20t3xoG-dQfMO94LGOl9AxRTkaz~TykFY-voqaTQI,AQACAAE/FAFS/47/ > > -Don't think out of the box: destroy it!- > ___ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Using standard ports of encrypted protocols
Arne Babenhauserheide wrote: > On Wednesday, 20. May 2009 18:14:53 Matthew Toseland wrote: >> Depends on your threat model. Freenet traffic clearly doesn't look like >> these without proper stego transport plugins, and the connections between >> nodes definitely don't look like them, unless what you are imitating is >> purely peer to peer, in which case you need to look at the other nodes' >> connections as well and/or the timing. > > Is a steganography transport plugin planned? > Yes, but that's long term stuff. The important bit is the plugin system. Stego transports shouldn't be bundled by default otherwise they become part of the protocol and that defeats the purpose. NextGen$ ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Friday 15 May 2009 17:05:09 Robert Hailey wrote: > > On May 14, 2009, at 5:06 PM, Matthew Toseland wrote: > > > On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: > >> > >> On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: > >> > >>> Because we were both on the same LAN, it did not connect, until I > >>> told him to > >>> set it to allow local addresses on that peer. There should be a > >>> checkbox when > >>> adding a noderef, defaulting to on, "Friend may be on the same local > >>> network > >>> as me" or something. (#3098) > >> > >> I think that it should be possible to automatically detect this. > >> Specifically, if we detect that our peer has the same "external > >> address" as us, try and connect locally. Is that a reliable > >> indicator? > > > > Not very (what if it changes?) ... we don't want darknet peers to > > cause us to > > connect to addresses on our LAN ... otherwise the solution is simply > > to try > > the local addresses included ... > > I agree that we don't want to try the local addresses of ~all~ our > peers; local connections are in principal an exception and not cause > enough to be sending so much local garbage handshaking traffic (that > could give away a freenet node). > > But I think this is the right way to go... If it is not defined for a > given peer (allow/disallow local connections), then we could just > calculate the default boolean as > his.extAddresses.containsAny(my.extAddresses) if it matches, then > there is an excellent chance of it being a local connection (99%). If > it changes, that's great! The decision to try local connections would > change too! As it's probably a laptop that has floated out of the LAN > (and we would want to stop sending handshakes to the local address > anyway). At worst we might send a few garbage handshakes to local non- > freenet machine until we connect to the node & find it's new external > address. > > The reason I think this would solve the problem because (I think) the > principal reason that the nodes could not communicate is because the > gateway would have to send a packet to itself (many inexpensive or > firewalled ones will not). > > e.g. > internal -> firewall -> external (generally works w/ current > countermeasures) > > internal --> > firewall > internal <-- > > Does not work (at least for me). So what I propose is really an > extension of "detecting the problem" (the gateway which has the same > external ip). Don't know about multihoming, but I presume that this is > works in the common case. Nonetheless it is highly unreliable as a way to detect it with dynamic external IP address, especially given that the two nodes are unable to communicate by any other means. 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] XMLLibrarian binary on downloads.freenetproject.org
On Thu, May 21, 2009 at 5:23 PM, Matthew Toseland wrote: > On Thursday 21 May 2009 03:53:04 you wrote: >> XMLLibrarian on downloads.freenetproject.org was compiled with Java 6 >> and emitting UnsupportedClassVersionError. >> Please recompile it with Java 5 and update the binary. >> > It was compiled with your plugin build script iirc. Please update the build > script for all the plugins to use java 5. I have just updated with target="1.5" at 222d686 HOWEVER, you should always build with a 1.5 JDK. This is the only way to ensure it does not use any Java 6 specific API (accidentially). -- ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Usability test results
On Friday 15 May 2009 17:05:09 Robert Hailey wrote: > > On May 14, 2009, at 5:06 PM, Matthew Toseland wrote: > > > On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: > >> > >> On May 14, 2009, at 12:17 PM, Matthew Toseland wrote: > >> > >>> Once connected to my node, it repeatedly RNFed on the top block of > >>> TUFI. > >>> Performance with one peer is expected to be poor, but it is worse > >>> than IMHO > >>> it could be. Some sort of fair sharing scheme ought to allow a > >>> darknet peer > >>> that isn't doing much to have a few requests accepted while we are > >>> rejecting > >>> tons of requests from other darknet peers and opennet peers. (#3101) > >> > >> I second that, but I'm not sure as to the best implementation. > >> > >> On the surface this appears to be the same issue as balancing local/ > >> remote requests. i.e. if your node is busy doing everyone else's > >> work, > >> your requests should take clear advantage when you finally get around > >> to clicking a link. > > > > Possibly. It is indeed a load balancing problem. Queueing will help, > > or maybe > > simulated queueing. > >> > >> I think this conflicts with the current throttling mechanism; piling > >> on requests till one or both nodes say 'enough', > > > > Is this how it works now? > > Yep. To the best of my understanding... > > Q: How do we determine if we are going to take a remote request? > A: If there is "room" to incur it's expected bandwidth. > > Premise-1: all chks transfer at an equal rate > > Result-1: new transfers squeeze bandwidth from other transfers. > Result-2: a node will accept any number of transfers until such a > point that all of them would go over the maximum allowed transfer time. > > Effectively making every transfer to the slowest-allowed transfer (not > counting local traffic or non-busy nodes). This is why I advocated > lowering the slowest transfer time as a general speedup. Which we tried, and it caused a massive slowDOWN. Mostly because most requests do not result in a transfer, so we need a substantial number of requests to compensate for that. The real solution is a bulk flag, but we cannot implement that until 0.7.5 has shipped. > > >> and if we reserve > >> some space we will not hit our bandwidth goal. Or that requests are > >> actually "competing" like collisions on a busy ethernet channel > >> rather > >> than having an order. > > > > Yes, it is very much like that. > > Does that mean that the logical alternative is token passing? > > In fact... guarantee-able request acceptance (token passing), might > actually be a logical prerequisite for a fair-queueing system. > > Interestingly any node can measure how many requests it can accept > right now (for bandwidth), but only can guess as to it's peers (by > backoff); so then, we may well accept requests which we cannot make > good on, because our peers cannot accept them (ethernet collision > logic at every hop). Yes. On 0.5 we tried to estimate the rate at which we could accept requests and publish this, but we could never take our peers' inter-request times into account when calculating our own without getting network collapse. Some system involving queueing is likely the best we can achieve. Token passing (advertising to several nodes when we have an available slot) is really just an essential optimisation for queueing. But by definition queueing results in all requests spending longer on a hop, and some requests spending much longer (and perhaps timing out). Simulated queueing (randomly dropping requests to maintain queue lengths, but routing immediately those we accept) might be an alternative for lower latency at the cost of lower accuracy. Maximum queue times could be radically different for requests with and without the bulk flag. > > >> One thing that I was playing around with earlier was re-factoring > >> PacketThrottle to be viewed from the queue-side. Rather than > >> "sendThrottledPacket" blocking till "a good time" to enqueue a > >> message > >> based on the throttle, that all the packets would be serially > >> available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns > >> the next 'n' packets). > > > > Good idea... I thought it was somewhat like that already? It is > > important in > > some cases for it to block... > > Only in that they feed an outbound message queue rather than actually > sending a packet. But it looks to me like a bit of cruft from a > previous design. > > In any case, you have a design note in the comments of PacketThrottle > that it would be better to have a sorted list or red/black tree rather > than a ticket system (where all threads wakeup); maybe a new class > needs to be written (BulkQueue) that *only* interleaves waiters (round > robin?) and the packet throttle then used only for actually sending > packets. Yeah... signature.asc Description: This is a digitally signed message part. _
Re: [freenet-dev] Separate browser or not
Matthew Toseland skrev: > On Sunday 17 May 2009 11:43:26 Zero3 wrote: >> Colin Davis skrev: >>> As implemented currently, Private browsing is all-or-nothing in >>> FF3.5beta4 and Safari, but Google Chrome is per-window. Firefox has issues with coalescing windows, no? If I run firefox with > command line options to use one profile, it may use another if a window is > already open, there are things like that... Is opening a window with privacy mode enabled safe and reliable? >> I guess both ways should work fine for us? We simply launch the browser >> with the command line arguments, and let the browser handle the >> window/tab management? > > No, Firefox might very well end up opening a window in non-incognito mode. Surely such bug would be fixed before the beta turns into final? - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Updating helper executables on Windows
Matthew Toseland skrev: > On Sunday 17 May 2009 11:41:00 Zero3 wrote: >> Matthew Toseland skrev: Detecting the version of an installed application in the launcher (at least in Windows) shouldn't be a problem. It will most likely be registered in the registry next to the .exe path we are checking already for the individual browsers. We can also check the version info of .exes as an alternative (most Windows applications are compiled with various static info like version and author). The Windows launcher is already running Chrome with a command line argument making it start in privacy mode btw. >>> You should prioritise Chrome with privacy mode over Firefox without it. >> Agreed: https://bugs.freenetproject.org/view.php?id=3118. > > I thought you had already done this? At time of writing, no. But since then I managed to figure git out and changed it (hence the bug is now "resolved"). ... which leads to another thing to consider: We need to make it possible to update the start.exe/stop.exe/freenetlauncher.exe files for existing users when new updates are made available. The easiest way to do this right now would probably be to add them to the update.cmd script. - Zero3 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Freenet 0.7 build 1210
Freenet 0.7 build 1210 is out. Sorry for the delay in announcing it. It will be mandatory at midnight. There was also a minor git mess relating to tagging - it was released from a local branch because I forgot to push before tagging, although it has been merged back into master now. If you are building from source you need to either clone the tag or do "git fetch -t origin" to fetch orphan tags. Changes: - Startup fix: you can now move the persistent temp directory, as long as you update freenet.ini accordingly. This is also an issue when moving the node. - Startup fix: Deleting the persistent temp dir and moving the node failed to startup - Let the node start up even if the database is unrecoverably corrupted. Tell the user what the situation is, and refuse to do any persistent requests or inserts. - Don't commit every database job immediately, unless we need to for memory reasons (some job types), for UI reasons (e.g. starting a request), every 30 seconds, or after every job if the new alwaysCommit config option is enabled. This should reduce disk I/O and improve performance significantly on some systems with big queues. - Fix various client layer bugs, in freesite inserts and other things. - SSK insert collision handling fix - store the data as well as forwarding it. - Minor crypto optimisation in handling SSKs. - First time wizard: remove the memory limit selection page, add a page to ask the user whether to auto-update Freenet and whether to load JSTUN and UPnP (this may reduce performance on a new node *slightly*, but we don't want to have to ask in the installer), warn the user about monthly bandwidth usage, always show the bandwidth and store size pages, minor fixes. - Enable javascript support by default in fproxy, minor fixes, get rid of the MIME type column on the queue page in simple mode, more tolerant parsing of noderefs and bulk download lists. - Fix various connection level bugs, which hopefully once everyone has 1210 will fix the forced disconnected because not acknowledging packets bug. In simulation this fixes "Unmatchable packet from ", which really shouldn't happen! - Minor plugin code improvements (new APIs, require XMLLibrarian version 22). - Internal bugfix which hopefully only was breaking IPv6 address detection from peers. - Internal bugfix relating to moving files, might have caused bugs in several places. - Don't let default changes override the local option for whether to preallocate the store. - Lots of internal cleanup and some work on the many-nodes-one-VM simulators / automated network tests, including a new long-term data retrievability test. Also, the XMLLibrarian plugin now shows a search's progress without using javascript, and immediately from typing a search on the homepage (thanks mikeb). KeyExplorer 0.4 beta is out, and there has been more work on the WoT web of trust plugin (thanks saces). A bugfix in the UPnP plugin, and as previously mentioned we deployed the new windows installer (thanks Zero3). Thanks to: sdiz 3BUIb3S50i platy nextgens saces juiceman 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] Plugin snapshots
Please post on the list when you want me to distribute a new snapshot of a plugin. Thanks. 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] Updating helper executables on Windows
On Thu, May 21, 2009 at 6:58 AM, Zero3 wrote: > Matthew Toseland skrev: >> On Sunday 17 May 2009 11:41:00 Zero3 wrote: >>> Matthew Toseland skrev: > Detecting the version of an installed application in the launcher (at > least in Windows) shouldn't be a problem. It will most likely be > registered in the registry next to the .exe path we are checking already > for the individual browsers. We can also check the version info of .exes > as an alternative (most Windows applications are compiled with various > static info like version and author). The Windows launcher is already > running Chrome with a command line argument making it start in privacy > mode btw. You should prioritise Chrome with privacy mode over Firefox without it. >>> Agreed: https://bugs.freenetproject.org/view.php?id=3118. >> >> I thought you had already done this? > > At time of writing, no. But since then I managed to figure git out and > changed it (hence the bug is now "resolved"). > > ... which leads to another thing to consider: We need to make it > possible to update the start.exe/stop.exe/freenetlauncher.exe files for > existing users when new updates are made available. > > The easiest way to do this right now would probably be to add them to > the update.cmd script. > > - Zero3 > ___ > Devl mailing list > Devl@freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > I would be happy to do this, however I will need a defined directory structure on the download site, with known file names. Like we have the .url link for the freenet.jar. I believe I can use the .sha1 file to check for updates if you want to have a static name. ie wrapper_win32x86.exe etc. Also I would prefer to not have them inside a zip unless we have have a built-in unzipping program in Windows I can reliably call by command line. Otherwise we will have to bundle yet another third party utility. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Separate browser or not
As an aside, Matthew had asked in the past about reducing the number of connections from the browser to the node. Digg's new library may be able to assist- It breaks images into data uris, and then inlines them. Even if Freenet doesn't want to use the library, inlining images as Data URIs may improve load times. Just a thought. -CPD http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Updating helper executables on Windows
On May 21, 2009, at 11:32 AM, Juiceman wrote: > On Thu, May 21, 2009 at 6:58 AM, Zero3 > wrote: >> Matthew Toseland skrev: >>> On Sunday 17 May 2009 11:41:00 Zero3 wrote: Matthew Toseland skrev: >> Detecting the version of an installed application in the >> launcher (at >> least in Windows) shouldn't be a problem. It will most likely be >> registered in the registry next to the .exe path we are >> checking already >> for the individual browsers. We can also check the version info >> of .exes >> as an alternative (most Windows applications are compiled with >> various >> static info like version and author). The Windows launcher is >> already >> running Chrome with a command line argument making it start in >> privacy >> mode btw. > You should prioritise Chrome with privacy mode over Firefox > without it. Agreed: https://bugs.freenetproject.org/view.php?id=3118. >>> >>> I thought you had already done this? >> >> At time of writing, no. But since then I managed to figure git out >> and >> changed it (hence the bug is now "resolved"). >> >> ... which leads to another thing to consider: We need to make it >> possible to update the start.exe/stop.exe/freenetlauncher.exe files >> for >> existing users when new updates are made available. >> >> The easiest way to do this right now would probably be to add them to >> the update.cmd script. >> >> - Zero3 >> > > I would be happy to do this, however I will need a defined directory > structure on the download site, with known file names. Like we have > the .url link for the freenet.jar. I believe I can use the .sha1 file > to check for updates if you want to have a static name. ie > wrapper_win32x86.exe etc. Also I would prefer to not have them inside > a zip unless we have have a built-in unzipping program in Windows I > can reliably call by command line. Otherwise we will have to bundle > yet another third party utility. If it helps, my understanding is that zip & jar are cross compatible. Or more specifically, that a jar is a zip file with extra flags and a manifest file. -- Robert Hailey ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Separate browser or not
On Thursday 21 May 2009 18:54:38 Colin Davis wrote: > As an aside, Matthew had asked in the past about reducing the number of > connections from the browser to the node. > > Digg's new library may be able to assist- It breaks images into data uris, > and then inlines them. > > Even if Freenet doesn't want to use the library, inlining images as Data > URIs may improve load times. Just a thought. > -CPD Well it's not the stuff that we have already fetched that slows things down, it's the images we have to wait for. > > http://ajaxian.com/archives/digg-shows-multipart-xmlhttprequest-prototype 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] Separate browser or not
On Thursday 21 May 2009 11:54:32 Zero3 wrote: > Matthew Toseland skrev: > > On Sunday 17 May 2009 11:43:26 Zero3 wrote: > >> Colin Davis skrev: > >>> As implemented currently, Private browsing is all-or-nothing in > >>> FF3.5beta4 and Safari, but Google Chrome is per-window. > Firefox has issues with coalescing windows, no? If I run firefox with > > command > line options to use one profile, it may use another if a window is > > already > open, there are things like that... Is opening a window with privacy mode > enabled safe and reliable? > >> I guess both ways should work fine for us? We simply launch the browser > >> with the command line arguments, and let the browser handle the > >> window/tab management? > > > > No, Firefox might very well end up opening a window in non-incognito mode. > > Surely such bug would be fixed before the beta turns into final? I have no idea, but it does exactly the above with profiles sometimes iirc. 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] Why WoTs won't work....
Interesting discussion from Frost, especially the last post at the bottom. Its about WoTs in general and why they won't work. - hahaha...@yle3zhs5lkiwe3fdjyqlcf5+rka - 2009.04.05 - 02:28:11GMT - I had to forward this one here. --- jezreel℺X~GLTTHo9aaYtIpGT6OOyBMMFwl3b8LwFu6TUw9Q82E sent via FMS on 2009-04-05 at 01:31:54GMT --- Probably not an amazing subject, but FMS is so dead lately so what the hell. Falafel, why do some of the folks posting to Frost hate you so much? In particular Luke771 and VolodyA. You generally seem like a nice identity so I'm just curious. -- jezr...@pbxwgrdegrigwuteoz3tc6cfla2xu3trmi2tgr2enfrvi4bxkzlectshfvyw2wcxkrffslccijku4z2om5gtoojrpzdfcolkovtdawjuifigkrcqjbevsvrnla2xotcdpfvw6lkmkzzsyqkrifbucqkf.freemail ;)) - VolodyA! V a...@r0pa7z7ja1haf2xttt7aklre+yw - 2009.04.11 - 12:11:26GMT - I should point out i do not hate falafel, i do not know him. I do hate what he is doing to Freenet, however. If he was to stop supporting intruduction of censorship on Freenet i would not say anything bad about him. In fact i tend to agree with much of what he has to say on other subjects. -- May all the sentient beings benefit from our conversation. - denmin...@dlkkaikia79j4ovpbgfk4znh25y - 2009.04.14 - 16:13:07GMT - Falafel is doing nothing. If a single guy can make the protocol not work, then the protocol is shitty from the start and we need to write a new one. - Anonymous - 2009.04.14 - 20:46:59GMT - The only shit around here is spewing from the mouths of those who don't understand how it works. No one can stop you from seeing what you want to see. Anyone who tells you otherwise is spreading misinformation. - luke...@ch4jcmdc27eeqm9cw_wvju+coim - 2009.05.04 - 01:01:46GMT - No one can really censor FMS alright, BUT there IS a problem with those 'censored trust lists' anyway. The existance of censored trust lists forces users to actively maintain their own trust lists, the WoT wont work 'on its own' as it would if everyone used it the way it's supposed to. Let me try to explain: if everyone used wot to block flood attacks and nothing else, new users wouldnt need to try and find out which trust lists are 'good', they wouldnt need to work on thir trust lists for hours every day, try to spot censors or "guys who wont block pedos", they could simply use FMS and occasianlly set a high trust for someone they actually trust, or lower the trust for someone they caught spamming But the current situation makes FMS a pain in the ass. Users have to work on your trust lists regularly, and new users risk (and probably do) to have some of the content blocked by some censor because the guy posted one message on a board that the censor found 'immoral'. It may take time until the new user figures out which trust lists to use, and there's a very real risk that he would think that it isnt worth the hassle and give up on FMS completely. I did that, others did that, and more will. THAT is the real problem with the Little Brothers, not their non-existent ability to censor content. they cant censor anything and they know it. But they can and do make FMS a pain in the ass to use. Another problem is that, assuming that the fms community will survive (which i dontthink it will), it my end up split into a number of closed sub-communities that refuse to talk to each other. But this is only a guess, so far. We'll have to see how it turns out. In the meantime, making FMS into a PITa has been done already, that is why FMS is as good as dead, and that's why I think that invesiting develpers' time and effort into WoT and Freetalk is a huge waste: FMS failed because of human stupidity and arrogance, and so will Freetalk/WoT, and I really cant understand why the devs cant see the obvious (or refuse to admit it) BTW, I dont hate Falafel. Hate costs energy. A lot of it. -- FAFS - the Freenet Applications FreeSite u...@ugb~uuscsidmi-ze8laze~o3buib3s50i25riwdh99m,9T20t3xoG-dQfMO94LGOl9AxRTkaz~TykFY-voqaTQI,AQACAAE/FAFS/47/ -Don't think out of the box: destroy it!- ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] update.cmd in java-based installer
Are all the changes made to update.cmd compatible with the java-based installer? For example, juiceman removed a bunch of commands relating to start.cmd; certainly I haven't tested my changes with the java-based installer. Also, do we want to get rid of Windows support from the java-based installer? The website always shows the exe for windows users now... Oh, and you didn't write version 3.0 - at least not all of it. :) 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 Sun, May 10, 2009 at 12:57 AM, wrote: > Interesting discussion from Frost, especially the last post at the bottom. > Its about WoTs in general and why they won't work. > There are no (new) interesting bits. The pain is well known among developers, repeating/explaining won't change it. If you want to have an alternative, do it with a *FULL PROPOSAL* (with the all advantage / disadvantage listed; impact on the network; etc...), not just "Hey! Why not do this " ... This is wasting everybody's energy. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] update.cmd in java-based installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, May 21, 2009 at 4:19 PM, Matthew Toseland wrote: > Are all the changes made to update.cmd compatible with the java-based > installer? For example, juiceman removed a bunch of commands relating to > start.cmd; certainly I haven't tested my changes with the java-based > installer. I've always coded it assuming it would be used for both installers, so unless there is a bug, yes. =) I would prefer that there is only one update.cmd on the website. > > Also, do we want to get rid of Windows support from the java-based installer? > The website always shows the exe for windows users now... Hmm. The new installer is nice... Have we received any reports of it not working? I don't see any reason to remove support unnecessarily... It is not much work to copy updates to both branches. > > Oh, and you didn't write version 3.0 - at least not all of it. :) I'll just change it to read "contributions by Juiceman" on next commit. =) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAkoWAZAACgkQ4esu1mlKOs8g5QCfS3h76lE+dBmZLeLTp30ArgRR I+gAnjYsuPWByBr9atZO6K4+rBjxt0l1 =Rsmn -END PGP SIGNATURE- ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Why WoTs won't work....
It's not all that interesting. It has been discussed to death many times. The Advogato algorithm (or something like it) solves this problem (not perfectly, but far, far better than the current FMS / WoT alchemy), as I have explained in great detail. Evan Daniel On Sat, May 9, 2009 at 12:57 PM, wrote: > Interesting discussion from Frost, especially the last post at the bottom. > Its about WoTs in general and why they won't work. > > > > - hahaha...@yle3zhs5lkiwe3fdjyqlcf5+rka - 2009.04.05 - 02:28:11GMT > - > > I had to forward this one here. > > --- jezreel℺X~GLTTHo9aaYtIpGT6OOyBMMFwl3b8LwFu6TUw9Q82E sent via FMS on > 2009-04-05 at 01:31:54GMT --- > > Probably not an amazing subject, but FMS is so dead lately so what the > hell. Falafel, why do some of the folks posting to Frost hate you so > much? In particular Luke771 and VolodyA. You generally seem like a > nice identity so I'm just curious. > -- > jezr...@pbxwgrdegrigwuteoz3tc6cfla2xu3trmi2tgr2enfrvi4bxkzlectshfvyw2wcxkrffslccijku4z2om5gtoojrpzdfcolkovtdawjuifigkrcqjbevsvrnla2xotcdpfvw6lkmkzzsyqkrifbucqkf.freemail > > ;)) > > - VolodyA! V a...@r0pa7z7ja1haf2xttt7aklre+yw - 2009.04.11 - > 12:11:26GMT - > > I should point out i do not hate falafel, i do not know him. I do hate what > he is doing to Freenet, however. If he was to stop supporting intruduction of > censorship on Freenet i would not say anything bad about him. > > In fact i tend to agree with much of what he has to say on other subjects. > > -- > May all the sentient beings benefit from our conversation. > > - denmin...@dlkkaikia79j4ovpbgfk4znh25y - 2009.04.14 - 16:13:07GMT > - > > Falafel is doing nothing. If a single guy can make the protocol not work, > then the protocol is shitty from the start and we need to write a new one. > > - Anonymous - 2009.04.14 - 20:46:59GMT - > > The only shit around here is spewing from the mouths of those who don't > understand how it works. No one can stop you from seeing what you want to > see. Anyone who tells you otherwise is spreading misinformation. > > - luke...@ch4jcmdc27eeqm9cw_wvju+coim - 2009.05.04 - 01:01:46GMT - > > > No one can really censor FMS alright, BUT there IS a problem with those > 'censored trust lists' anyway. > The existance of censored trust lists forces users to actively maintain their > own trust lists, the WoT wont work 'on its own' as it would if everyone used > it the way it's supposed to. > > Let me try to explain: if everyone used wot to block flood attacks and > nothing else, new users wouldnt need to try and find out which trust lists > are 'good', they wouldnt need to work on thir trust lists for hours every > day, try to spot censors or "guys who wont block pedos", they could simply > use FMS and occasianlly set a high trust for someone they actually trust, or > lower the trust for someone they caught spamming > > But the current situation makes FMS a pain in the ass. Users have to work on > your trust lists regularly, and new users risk (and probably do) to have some > of the content blocked by some censor because the guy posted one message on a > board that the censor found 'immoral'. > > It may take time until the new user figures out which trust lists to use, and > there's a very real risk that he would think that it isnt worth the hassle > and give up on FMS completely. > I did that, others did that, and more will. > > THAT is the real problem with the Little Brothers, not their non-existent > ability to censor content. they cant censor anything and they know it. But > they can and do make FMS a pain in the ass to use. > > Another problem is that, assuming that the fms community will survive (which > i dontthink it will), it my end up split into a number of closed > sub-communities that refuse to talk to each other. But this is only a guess, > so far. We'll have to see how it turns out. > > In the meantime, making FMS into a PITa has been done already, that is why > FMS is as good as dead, and that's why I think that invesiting develpers' > time and effort into WoT and Freetalk is a huge waste: FMS failed because of > human stupidity and arrogance, and so will Freetalk/WoT, and I really cant > understand why the devs cant see the obvious (or refuse to admit it) > > BTW, I dont hate Falafel. Hate costs energy. A lot of it. > -- > FAFS - the Freenet Applications FreeSite > u...@ugb~uuscsidmi-ze8laze~o3buib3s50i25riwdh99m,9T20t3xoG-dQfMO94LGOl9AxRTkaz~TykFY-voqaTQI,AQACAAE/FAFS/47/ > > -Don't think out of the box: destroy it!- > ___ > 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