[freenet-dev] Merging zidel/next into Freemail v0.2 fred-staging/master
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The stuff from toads original email that I didn't quote:
Freemail_wot:
Merged this, but there are various things to deal with before
releasing it. Some of them serious.
(My version of changelog, I'm happy to keep yours, issues follow after)
Freemail v0.2.4: Reviewed zidel/next and merged into staging/master,
up to 59a5ac628c14a7437db66329343cc0a0d5cb08a7
IMAP:
- - Simplify, refactor parsing of ranges, remove duplicated code.
- - Error handling/checking/messages.
- - Logging.
- - Set Recent flag when copying message.
- - Print [HEADER] in BODY[HEADER] fetch response
- - Lots of tests / lots of work on tests.
- -- Increase protocol timeout to 10s.
- -- Parameterised tests. (Especially for l10n issues)
- -- Reduce duplication.
- - Simplify copy code.
- - Don't try to remove recent flag if not set.
- - Handle single parenthesis around entire search.
General:
- - Charset support: Factor out MailMessage.getBodyReader().
Quoted-printable, base64 support (the message on disk is all 7-bit,
but a charset is specified in the header for the decoded bytes).
- - EncodingOutputStream: Encode messages sent via web interface.
- - Tests.
- -- Add support for tests.extensive flag.
- -- SMTP tests.
- -- Minor refactoring supporting tests.
- -- Various mock classes.
- -- Data for 2 fake mailsites, with addresses etc.
- -- Centralise/dedupe hardcoded identity data in tests, and test
identity creation.
- -- MessageTransportTest.
- -- Logging in unit tests (test.verbose)
- -- Add tools for sending and waiting for messages.
- -- ...
- - Flags fix.
- - Changelog: TODO deal with this.
- - FCPConnection: Always call super.finalize()
- - Various minor cleanups/refactoring.
- - Handle invalid From: header.
- - I18N: Specify date format more exactly.
- - I18N: getBytes("UTF-8") not getBytes(). Don't fallback to default in
MailSite.
- - Checks for impossible cases / future code changes.
- - Javadocs.
- - Indenting.
- - Use JUnit 4.
- - Fix some locale dependant bugs.
- - Fail auth for unknown account name.
- - Minor refactoring/cleanup.
- -- Move thread pools to Freemail from FreemailPlugin (reduce
dependencies), fetch via instance method.
- -- ...
- - SMTP:
- -- Remove dot padding when receiving message.
- -- Check result when sending message on messageSender.
- -- Command formatting.
- - Check for no RTS KSK on mailsite.
- - Don't move MailMessage when storing flags if src == dest
- - Handle WoT errors when matching identities.
- - Error messages.
- - Missing finally{close()}'s.
- - Update freesite link in welcome mail.
- - Logging.
- - Imports.
- - Add copyright headers.
- - Generate message ID's randomly, not based on date.
- - Replace the whole message ID, not just the domain, in
MailHeaderFilter, if the domain is not allowed.
- - Docs: Spec: define acronyms, fix section reference, fix quotes.
- - Add French translation.
Web interface:
- - Add About page with server and account info.
- - Use medium format for date/time.
- - Refactor, return an HTTPResponse (make testing easier) from WebPage's.
- - WoT Fallbacks:
- -- Outbox: Don't show nickname if identity not in WoT.
- - Don't register toadlets in constructor.
- - Close the correct stream after reading message content in
MessageToadlet.
- - Handle messages with no From: header.
Build scripts etc:
- - checkcommit script: document, various improvements.
- - cobertura script (unit test coverage report).
- - checkstyle improvements.
- - test.xml_output -> output junit XML to build-test (e.g. for jenkins)
- - includeantruntime=false
- - new default target, dist no longer depends on unit and checkstyle-auto
- - Add descriptions for clean targets
- - Expand some long lines in build.xml.
- - Only run tests in org/freenetproject/freemail
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJR++NlAAoJEL0Rn1Vb3j1/8MoP/iQpcqiIvoamErB3NvaTV4UL
/YiXmwHL7yxZ156ZuGYLcjpyl1Q1lRSGTuIj0ekSsvDULk2asxiwG05JavF1YpYV
FTeP9jDN9Lu6yEYC8rdFiswtOb3/f2GmBUziVGLv19Ff04oVDocr6jQEi7Yh0RI+
VC/3hJ4cyCugrxRpAuLlbOMceAnUvjhYy02S618/Q0CtQ/wdri+J56xnej2W1Awq
epieX0+x+NAa9EMscCzcWqAtTAxl/e/+5gIw85ZevCU8D2Qrds9tiH+eOuxZc7xm
6mRDxVkZSDhoPWtD7OypOhwMKNfXGiSTOb7NhifszSmFVJMugmYl7o33pqNFA7bS
ESmQxTaoNlLNPTtAIbt4yF2Wjx4zx0ed1YZGyARH5okXzWv7UMHCYV94p1VJpWW+
smB3kb5eHeNx8NJCSnEingIO769hx5OCeRgfiqroqJSZtMcq87u97xG4e+bbX2QJ
HHbR36w55BZQxFxxQsgftasBUVCw8N4PKh+cmStydJQ/EeHuEYzSOmuMwt9Ras0H
dAgkUcKuaoPwRNPt6kAi6jzrhc6GQzbwrcpa6N9Zmjx16T80T+YfyS9K0PEzg6BF
2s4sjal9sYmhmOc5y0GPD4gglM2OxoHPg9WN2BXKi+mk3YBvGxRmTaZfdy0qE8q8
RpxZIlHgJ63A5QfzvPQa
=IfQW
-END PGP SIGNATURE-
[freenet-dev] Merging zidel/next into Freemail v0.2 fred-staging/master
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/02/2013 03:47 PM, Matthew Toseland wrote:
> On Thursday 01 Aug 2013 19:35:47 Martin Nyhus wrote:
>> I need to go though this is more detail, but some initial
>> thoughts:
>
> Any reason not to forward/CC this to devl?
Nope. Your original email wasn't sent there so I simply didn't think
about it. I'll send the stuff from your email that I didn't quote
separately.
>>
>> On 08/01/2013 02:47 PM, Matthew Toseland wrote:
>>> 7c9b4d08894f319d0e7022a02d35d96899261958 - not safe, surely? -
>>> headers can be encoded, can't they? is that implemented in
>>> Freemail? - this part only deals with body ... but elsewhere
>>> there must be support for quoted-printable etc in headers. in
>>> which case this is bogus. Do they use the same charset? It
>>> would be OK to pass through if the charset is only used for the
>>> body - but the charset for the headers MUST be known. (and we
>>> should test this). - it looks like there is support for encoded
>>> headers. but it seems to be completely separate from support
>>> for encoded body? SECURITY: quoted-printable etc in headers:
>>> MUST NOT fallback to raw content!
>>
>> That function is only used for displaying things on web pages, so
>> it is safe assuming the body is 7bit clean (as it should be).
>> Since we don't actually check the content before displaying or
>> when receiving we should either:
>
> If it's only displayed on a web page, then surely we add it with
> new HTMLNode("#", string)? If so, it's safe, period.
>
> Having said that, my main concern here is header filtering: From,
> To, etc. Stuff that might be meaningful to clients and cause them
> to do bad things too. We don't decode before filtering? Should we?
> Will an encoded From always be rejected?
With the exception of the spoofed From header check, we don't do *any*
filtering of incoming messages. When clients connect via IMAP they get
the raw content we store on disk, the IMAP server doesn't decode stuff
for them. A future filter for incoming messages must of course decode
messages and generally try to parse what the clients will actually parse.
>> 1. Fall back to a mode that displays the raw content, but filters
>> out anything that isn't ASCII printable characters 2. Throw
>> UnsupportedEncodingException and display an error of some kind in
>> the web ui.
>>
>> So, it might be unsafe at the moment.
>
> If it's only the web interface then it's safe, although it may look
> garbled. And from the call trace it looks like this is the case.
>>
>> Headers can be encoded and decoding is implemented in
>> MailMessage.decodeHeader(). It seems to lack proper test
>> coverage, but it supports both quoted printable[1] (Q) and base64
>> (B) encodings. Charset support depends on the JVM. Encoded
>> headers can have different encodings (even within one header),
>> and it is not related to the body encoding at all. We throw on
>> unknown charsets/encodings in the headers.
>>
>> [1] Note that quoted printable in the headers doesn't mean the
>> same thing as quoted printable in the body!
>>
>>
>>> 40141456bf5457d395b9afac49d1ef3c48c054c5 - i don't understand
>>> how writeBuffer can assert the buffer is only whitespace and
>>> then handle the non-whitespace case? And anyway this is
>>> definitely not always going to be true?
>>
>> Not 100% sure I understand what is going on (bad sign), so I'll
>> have a look at it later. Looks to me like we only put whitespace
>> into the buffer (which makes sense). Needs fixing anyway, if only
>> to make it easier to understand.
>
> Okay, so it's just a bit generous in what it accepts in the for()
> loop, and unclear. And over-complicated as a result. There can only
> be space, tab or carriage return, and we only need to writeEncoded
> if it's a carriage return? Also you should rename the buffer, or at
> least document it, to reflect the fact that it's always
> whitespace.
I don't remember all the details, but e.g. you can't end a line with
whitespace, and you need to be careful about \r\n since it suddenly
has two meanings depending on the context etc. I'll read the RFC again
and
fix/clarify/document the code.
>>
>>> 60aa04c71a778ffd403c032b01b994c2251355d6 - TODO: Fix the
>>> changelog given the versions released weren't as planned. Or
>>> were they close enough? I did the recent releases so I guess I
>>> can deal with this?
>>
>> Would be nice if you could deal with this, especially since you
>> know which versions you actually released into the wild. Not that
>> many commits anyway, so I can review whatever you have time to do
>> and pick up the rest.
>
> Ok.
>>
>>> 843d4ddef927270bf322e032aef01d6bcb30cca6 - Logger.debug()
>>> should be if(logDEBUG)??? Or don't we use this in Freemail?
>>> Should we? I think it still has its own logger implementation
>>> ... Does it still work on the command line?
>>
>> There is no if(logDEBUG) in Freemail, nor do I think it is
>> needed. The amount of logging is
[freenet-dev] Infocalypse WoT Usage
(Reply split in two mails since I need the answer of toad for only one of them - for this one) On Tuesday, July 30, 2013 07:01:05 PM Steve Dougherty wrote: > > How do you obtain the list of identities which you offer the user to chose > > from? You should use GetIdentitiesByScore with positive score filter (and > > context filter "Infocalypse", I think it supports that as well). Where do > > you present him with the list? Ideally, the UI which shows the list > > should pass through the ID so you don't have to filter by nickname. > > There is no list to choose from. The user types something like "hg pull > freenet:p0s/WoT" and Infocalypse resolves it to a URI (not necessarily > one in the same subspace) and fetches it. > > > But I guess you might be using command line only so the user needs to be > > free to pass nicknames without ID? > > Yes. > > > In that case, I should probably implement > > "GetIdentitiesByPartialNickname". > > That would be very useful not only for this project but also for > anything that wants to have autocomplete. (Such as Freemail recipients > in the "to" field of the web interface.) Fine. Then I get your point now. Now the question is: When should I implement it? The next point on my roadmap is getting event-notifications in a merge-able state. This probably will take a full month. I had already delayed event-notifications for a month due to other work. Implementing GetIdentitiesByPartialNickname take a full week or even two. It would have to be done in a proper way to be persistent and use the database. How easy is it for you to work without this feature right now? Can you use a dummy-implementation until I finish event-notifications? Event-notifications would also be useful for you maybe to deliver pull-requests by solving a captcha of the person who shall receive the pull request. Toad, what do you think?
[freenet-dev] Infocalypse WoT Usage
(Reply split in two mails since I need the answer of toad for only one of them) On Tuesday, July 30, 2013 07:01:05 PM Steve Dougherty wrote: > On 07/30/2013 05:45 PM, xor wrote: > > On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote: > >> At p0s' request here's some information about how Infocalypse currently > >> uses WoT. > >> > >> Infocalypse sets a "vcs" context on identities when they create a > >> repository, and inserts a list of repositories under the identity's > >> subspace at /vcs/. > > > > "VCS" as in "Version control system" is a general term and hg/Infocalypse > > for sure is not the only one. > > This is the intent. OThere are fields to specify what VCS is being used > in both pull requests and the repository lists. One of the initial > design goals was to allow other source control systems to add support > for Freenet in the same way. I hope for the Infocalypse web UI Fred > plugin to be VCS agnostic so that it could be used with anything that > communicates with it properly over FCP. I guess that makes the name wrong. Generic code is usually a very good design so I appreciate this effort. However it is notable that the nature of open source development might still lead to multiple implementations of generic VCS systems. We already have an example of this with FMS and Freetalk both implementing the same service but being separate spaces due to incompatible design decisions. So I still vote for this: > > I think you should use "Infocalypse" as context name and as part of the > > URI. This would be coherent with "Freetalk" as Freetalk context name and > > URI subspace and "WebOfTrust" as WOT subspace.
[freenet-dev] [gsoc2013] Transport Layer - Update 2
"- As the look up of the field show, the easieset-to-use tool for such primitive plotting tasks seems to be JFreeChart. Any propositions?" Take care, JFreeChart points some dependencies with Fonts (with open-jdk). I am not sure that this open-jdk bug is solved. *cf.*: http://stackoverflow.com/questions/12212604/openjdk-font-dependencies nicolas - Nicolas Hernandez a-n - aleph-networks *PDG - CEO* http://www.aleph-networks.com On Thu, Aug 1, 2013 at 9:30 PM, Vladislav Sterzhanov wrote: > This one will be related to benchmarking and stats gathering : > - Repo > - Current functionality > - To-Do List for toadlet and stats > - Issues > > - > > | Repo > The repository for the GSoC-2013 Transport Layer Project, which I'm > developing can be found here (https://github.com/Quadrocube/fred-staging) > at the branch transport_layer_modifications (probably should rename it and > add another for actuall transport layer changes - the current code there is > related to the base for benchmarking only). > > | Current functionality > LinkStatistics class was presented to represent the gathered link indexes > and two LinkStatistics fields were added to a PeerNode - the first one > (linkStatsTotal) is used for attaching a benchmark-aware listener to it and > serves for benchmark measurements. The other LinkStatistics field in > PeerNode (shortRunLinkStats) will be utilized for a several actually > transport-related modifications. > LinkStatisticsToadlet acts as web-interface for the link sampling. Upon > activation (Connections to Friends - select "test connection" near the > friend's noderef - enter the sample size, press "Test conection"), it > attaches a listener (LinkStatistics.StatsChangeTracker) to a chosen > peerNode.linkStatsTotal, initiates a BulkTransfer of the given size, and > monitors several usefull for later analysis activities. Currently it > produces only a grand-total upon the end of the transfer but there are > callbacks introduced that can be used to build up a more precise dynamic > analytics. > Note: In order for this to work, both testing and tested peer should be > supplied with the version of freenet from this branch. Reason: it contains > the receiver-side modification to get rid of the need to manualy accept > each test. > > | To-do list for toadlet and stats > - Introduce the monitoring of other characteristics of a connection - > like e.g. bandwitdth measuring, average packet size seen, ... (Stats) > - Implement the dynamic logs in form of graphs - currently the most > vital things that will be usefull to have are (in order of importance): > congestion_window_utilized-from-time graph, bandwidth-from-time graph, > data_in_flight-from-time graph, payload_to_alldata-from-time, > averageRTT-from-time, etc.. (Toadlet) > - Localization (in a long term, not vital currently) (Toadlet) > - Forbid the link sampling in case of huge load on the monitored node. > There are already means to reject the test for the peer, but they are not > used currently (See NodeDispatcher.java) (Toadlet) > > | Issues > - As the look up of the field show, the easieset-to-use tool for such > primitive plotting tasks seems to be JFreeChart. Any propositions? > - Potentially very long locking in POST at toadlet - need to fix it > somehow. Once again, a long-term thing. > > After all that is ready, I am passing to the implementation of the todo > list discussed at the previous report and comparing the results obtained by > that implementation against the benchmark results of the current one. And > at last it will be possible to estimate the reasons for many suspicious > transfer failures (e.g. LAN-transfering 1MiB files for minutes) and fix > them. > > quadrocube > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
Re: [freenet-dev] Infocalypse WoT Usage
On Friday 02 Aug 2013 02:00:59 xor wrote: (Reply split in two mails since I need the answer of toad for only one of them - for this one) On Tuesday, July 30, 2013 07:01:05 PM Steve Dougherty wrote: How do you obtain the list of identities which you offer the user to chose from? You should use GetIdentitiesByScore with positive score filter (and context filter Infocalypse, I think it supports that as well). Where do you present him with the list? Ideally, the UI which shows the list should pass through the ID so you don't have to filter by nickname. There is no list to choose from. The user types something like hg pull freenet:p0s/WoT and Infocalypse resolves it to a URI (not necessarily one in the same subspace) and fetches it. But I guess you might be using command line only so the user needs to be free to pass nicknames without ID? Yes. In that case, I should probably implement GetIdentitiesByPartialNickname. That would be very useful not only for this project but also for anything that wants to have autocomplete. (Such as Freemail recipients in the to field of the web interface.) Fine. Then I get your point now. Now the question is: When should I implement it? The next point on my roadmap is getting event-notifications in a merge-able state. This probably will take a full month. I had already delayed event-notifications for a month due to other work. Implementing GetIdentitiesByPartialNickname take a full week or even two. It would have to be done in a proper way to be persistent and use the database. How easy is it for you to work without this feature right now? Can you use a dummy-implementation until I finish event-notifications? Event-notifications would also be useful for you maybe to deliver pull-requests by solving a captcha of the person who shall receive the pull request. Toad, what do you think? I'd bounce this back to operhiem1. Does p0s working on this in the relatively near future save you a lot of work? If not, it should be postponed until after event notifications. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Infocalypse WoT Usage
On 08/02/2013 08:22 AM, Matthew Toseland wrote: On Friday 02 Aug 2013 02:00:59 xor wrote: [snip] In that case, I should probably implement GetIdentitiesByPartialNickname. That would be very useful not only for this project but also for anything that wants to have autocomplete. (Such as Freemail recipients in the to field of the web interface.) Fine. Then I get your point now. Now the question is: When should I implement it? The next point on my roadmap is getting event-notifications in a merge-able state. This probably will take a full month. I had already delayed event-notifications for a month due to other work. Implementing GetIdentitiesByPartialNickname take a full week or even two. It would have to be done in a proper way to be persistent and use the database. How easy is it for you to work without this feature right now? Can you use a dummy-implementation until I finish event-notifications? Event-notifications would also be useful for you maybe to deliver pull-requests by solving a captcha of the person who shall receive the pull request. Toad, what do you think? I'd bounce this back to operhiem1. Does p0s working on this in the relatively near future save you a lot of work? If not, it should be postponed until after event notifications. I see no need to prioritize working on this in the near future. WoT-integrated Infocalypse features still work without GetIdentitiesByPartialNickname. It falls back to GetIdentity, which means for non-local identities the entire identity ID must be specified. This removes the convenience of partial matching, but it does still function. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] [gsoc2013] Transport Layer - Update 2
On Thursday 01 Aug 2013 20:30:36 Vladislav Sterzhanov wrote: This one will be related to benchmarking and stats gathering : - Repo - Current functionality - To-Do List for toadlet and stats - Issues - | Repo The repository for the GSoC-2013 Transport Layer Project, which I'm developing can be found here (https://github.com/Quadrocube/fred-staging) at the branch transport_layer_modifications (probably should rename it and add another for actuall transport layer changes - the current code there is related to the base for benchmarking only). | Current functionality LinkStatistics class was presented to represent the gathered link indexes and two LinkStatistics fields were added to a PeerNode - the first one (linkStatsTotal) is used for attaching a benchmark-aware listener to it and serves for benchmark measurements. The other LinkStatistics field in PeerNode (shortRunLinkStats) will be utilized for a several actually transport-related modifications. LinkStatisticsToadlet acts as web-interface for the link sampling. Upon activation (Connections to Friends - select test connection near the friend's noderef - enter the sample size, press Test conection), it attaches a listener (LinkStatistics.StatsChangeTracker) to a chosen peerNode.linkStatsTotal, initiates a BulkTransfer of the given size, and monitors several usefull for later analysis activities. Currently it produces only a grand-total upon the end of the transfer but there are callbacks introduced that can be used to build up a more precise dynamic analytics. Note: In order for this to work, both testing and tested peer should be supplied with the version of freenet from this branch. Reason: it contains the receiver-side modification to get rid of the need to manualy accept each test. | To-do list for toadlet and stats - Introduce the monitoring of other characteristics of a connection - like e.g. bandwitdth measuring, average packet size seen, ... (Stats) - Implement the dynamic logs in form of graphs - currently the most vital things that will be usefull to have are (in order of importance): congestion_window_utilized-from-time graph, bandwidth-from-time graph, data_in_flight-from-time graph, payload_to_alldata-from-time, averageRTT-from-time, etc.. (Toadlet) - Localization (in a long term, not vital currently) (Toadlet) - Forbid the link sampling in case of huge load on the monitored node. There are already means to reject the test for the peer, but they are not used currently (See NodeDispatcher.java) (Toadlet) | Issues - As the look up of the field show, the easieset-to-use tool for such primitive plotting tasks seems to be JFreeChart. Any propositions? - Potentially very long locking in POST at toadlet - need to fix it somehow. Once again, a long-term thing. After all that is ready, I am passing to the implementation of the todo list discussed at the previous report and comparing the results obtained by that implementation against the benchmark results of the current one. And at last it will be possible to estimate the reasons for many suspicious transfer failures (e.g. LAN-transfering 1MiB files for minutes) and fix them. quadrocube Generally this looks fine (up to 362bd85fa6eeba70d34eef1a3355ee5acc4a7ea9). When/if it's merged the commits may need to be reorganised (e.g. combine b0ecadf7a0556fe66a87ef3c75180e28acd9c93b and 2c438211b0382c0ba0baab099503fd6a5c119e6e). I can deal with that later though. Sending a test should be a POST button. This can block (though ideally it should be asynchronous). But doing it from a plain link is dangerous. This needs fixing before merging. I'm not sure what the conclusion was with the ByteCounter's? The bytes should be reported to the global stats but we can record them locally as well. Having said that, this part may not get merged at all. JFreeChart, like almost every other Java package, depends on the recursive security breach known as Maven. See the thread about that. We may or may not be able to solve this adequately in the near future. If you're not planning for this to be merged then e.g. fixing the test toadlet to use a POST button is not as much of an issue. But if it helps you to sort out the transport layer, I will certainly merge the transport layer changes. (Which should indeed be on a different branch). signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Thu, Jul 25, 2013 at 12:36:34PM +0100, Matthew Toseland wrote: Basically the security model is now an attacker has to outspend the defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of value, especially in conjunction with other protections. They do have potential anonymity issues, but we're talking about opennet where the attacker knows your IP address anyway. There's also a varient of proof-of-sacrifice where you prove you attempted to create Bitcoins, a proof that has no linkage to any other Bitcoin transaction. AFAICS this is a slightly more complex form of pay to join, with the dubious advantage that nobody gets the money. In theory this might help people to not think we're scammers (although transient mode is more important to that end) ... but by the time you've explained it, you've lost them anyway, so I doubt it's worth the additional complexity. Well any decentralized attempt to limit sybil attacks and other attacks via some kind of limited resource ultimately boils down to pay to join, the question is what are you paying and how likely are honest users to already have what they need to pay? It's likely that for the foreseeable future, any attempt to charge an entry fee will result in losing a lot of nodes... (Not existing nodes, but potential nodes). Social issues are a real concern - we have this same problem in Bitcoin with SPV nodes, like a light-weight smartphone wallet, that aren't contributing back to the network but are consuming resources. How do you distinguish between a botnet pretending to be tens of thousands of smart phones and tens of thousands of real ones? People are allergic to any kind of fee... Another option you might want to consider is proof-of-work. In some ways it's not as effective, because like I said before often the actual cost to attackers is less, but the social dimensions may be more effective. What are your thoughts there? The proof-of-work could easily be something that is gradually phased out and replaced by proof-of-useful-work as the opennet peer responds to more and more requests, doing useful work. -- 'peter'[:-1]@petertodd.org 00717df9323a96a2c158b1be0249d0762d3b966e861d728a7b67 signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Distributed Version Control Update #7: GSoC Midterm Edition
Our time together this summer now comes to a middle. Google Summer of Code midterm evaluations were this week. I'm happy to report that I passed and will stay in the program for the rest of the summer. By now I've been thinking about and working on this project for around three months, and there's enough done and enough clearly planned that I can make an effort to talk about it in more concrete, practical terms. You may want to grab a beverage - this will be longer than usual. Version control, also known as revision control and source control, is a type of software that allows labeling and managing changes to files. These changes are stored in a series that make up a history of how files have changed over time. Examples of this are Concurrent Versions Systems (CVS), Subversion (SVN), Fossil, Monotone, Git, and Mercurial. These tools are often used to manage source code files for software projects. This project works with distributed version control software. (DVCS) The distributed part of distributed version control means there is no inherent centralization. Fossil, Monotone, Git, and Mercurial provide distributed version control. A collection of files and history created using version control is called a repository. Infocalypse is an extension for Mercurial which allows Mercurial to download and publish repositories using Freenet. Web of Trust is an official Freenet plugin which allows people to create and discover identities, which can be thought of as accounts for services on Freenet. [0] It is intended to provide spam resistance, and is somewhat similar to the trust system in Freenet Message System, [1] which is forum software for Freenet. The goal of this project is to add Web of Trust integration to Infocalypse to make Infocalypse easier to use, and to write a DVCS web interface plugin for Freenet for the same reason. As SomeDude requested, all this is designed so that other distributed version control software can add support for Freenet and Web of Trust in very similar ways, and hopefully even use the same web interface plugin without making changes to it. Before I started working on Infocalypse, it was primarily the product of djk and ArneBab. djk did maintenance and wrote the core functionality. ArneBab did maintenance and added integration with the normal (built-in) push (publish changes), pull (download changes), and clone (copy) commands, as well as support for accessing Freenet repositories using URIs starting with freenet:. So far, ArneBab's built-in command support and support for freenet: paths have not been incorporated into the official version of Infocalypse, nor has my work. I haven't yet tried contacting djk to discuss reviewing the changes. I plan to do so soon if djk doesn't pop up in one of these threads. Terminology: - WoT stands for Web of Trust. - A local WoT identity (currently called an own identity in the WoT interface) is controlled by the owner of the local Freenet installation. - A remote WoT identity is one other than the local identity whose perspective on other identities is in use. The local identity is in this case called the truster. Note that a local identity can also be a remote identity if there are multiple local identities. Local identities can still know of one another like any other identities. - A WoT identifier is of the format nickname@public key hash. The public key hash is also called the identity's ID. In addition to WoT, there is also LCWoT, which stands for Less Crappy Web of Trust. [2] It is a reimplementation of Web of Trust that has a slightly different feature set and is much faster. It is not a complete replacement for WoT. Its author, digger3, only wrote it because WoT has severe performance problems. digger3 does not intend to maintain it, especially if WoT's performance is fixed. Whenever a local identity is used, it is enough to specify enough of the nickname and ID to uniquely identify an identity. If I have the local identities Absolutely@wHllqvhRlGLZZrXwqgsFFGbv2V9S33lq~-MTIN2FvOw and A@uT0HBEQr17txtrkVt~auRBBFUtSubZQWeTAbIgXWMkc, A matches both, as does A@, but Ab and A@u match the first and second, respectively. With LCWoT this matching is also available for remote identities, but for WoT it is not. p0s, the primary WoT developer, plans to add support. [3] Infocalypse cannot resolve remote identities with the current (build 22) official release of WoT, though it should be able to in the next release. [4] Because support for built-in commands was added later, there tend to be two ways to do things: one through commands starting with fn- and another with push, pull, or clone. The following examples all work with the current (04a0c9d0c8c2) version of Infocalypse. Throughout these examples I use my WoT identity and the repository name pyProbe. Once configured with fn-setup, the following WoT-enabled operations are available: Publish a repository to Freenet: hg fn-create
