Re: [freenet-dev] [RFC] Freenet Summer of Toad

[Matthew Toseland]

On 28/04/15 18:03, Matthew Toseland wrote:
 On 10/04/15 02:27, Steve Dougherty wrote:
 Google Summer of Code didn't work out for us, but maybe we can have a
 Freenet Summer of Toad? It's not certain yet, but Matthew might be
 interested in working 35-hour weeks over the summer for FPI. He says he
 wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
 this while maintaining current operations will require a fundraiser. Are
 people interested in doing this?
 FYI I will not be working for Freenet in a paid capacity this summer.
 However my Part 2 project next year may be Freenet-related, possibly
 tunnels.
To clarify, I have a 10 week placement, but have around 6 weeks free. I
would be interested in working full time for a part of that - say 120 to
180 hours. Are we interested in hiring me for a shortish period, perhaps
a month?

We will need to raise more money fairly soon anyway, if Xor is going to
carry on.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] [RFC] Freenet Summer of Toad

[Matthew Toseland]

On 10/04/15 02:27, Steve Dougherty wrote:
 Google Summer of Code didn't work out for us, but maybe we can have a
 Freenet Summer of Toad? It's not certain yet, but Matthew might be
 interested in working 35-hour weeks over the summer for FPI. He says he
 wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
 this while maintaining current operations will require a fundraiser. Are
 people interested in doing this?
FYI I will not be working for Freenet in a paid capacity this summer.
However my Part 2 project next year may be Freenet-related, possibly
tunnels.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Am Samstag, 11. April 2015, 11:30:03 schrieb Matthew Toseland:
 No, this is *site inserts*. As I said, that code is pretty arcane, and I
 didn't write it (Saces did). It needs to be explained largely at the
 class level IMHO, because any other kind of inserts works differently.

On a conceptual level, I don’t consider site inserts that hard
(remember that I fixed minor bugs in the *ManifestPutter). The hard
part was understanding what all those put handlers do (or rather, what
a put handler is in the first place and why it is needed - concurrency
and all).

Other hard parts were knowing *why* a given size for a container is
useful and knowing how the different parts of fred tie together
(network packets, CHK size, SSK sizes, ...).

Best wishes,
Arne

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] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Am Samstag, 11. April 2015, 11:37:51 schrieb Matthew Toseland:
  If we have
  packet-based transports, plugins should be able to handle the
  transformation to and from TCP, so first doing only packet-based
  transports would give the capabilities to do more.
 Yes, but the whole idea of transport plugins is to make life easy for
 people implementing them, do all the hard stuff in fred itself, so we
 can have lots of them.

The first step is making it possible at all for people (without having
to hack at arcane parts of fred). Making it easy is only the second part.

And implementing packet-over-TCP isn’t that hard.

That said: Better have well-working darknet enhancements than
unfinished transport plugins, since we need the darknet enhancements
to really benefit from transport plugins, but not the other way round.

Best wishes,
Arne

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] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Am Samstag, 11. April 2015, 01:34:17 schrieb Matthew Toseland:
 Transport plugins are written by a GSoC student (Chetan), but need major
 refactoring and fixing of concurrency issues (plus implementing
 stream/TCP plugins)

How much work would it be if you left out stream stuff? If we have
packet-based transports, plugins should be able to handle the
transformation to and from TCP, so first doing only packet-based
transports would give the capabilities to do more.

 Traffic flow analysis is cheap nowadays, and no amount of stego can
 get us away from that.

We could simulate full traffic profiles: capture the traffic between
applications, then fake it. Video telephony, static noise on a mumble
chat (using an intermediate server for spreading it), bunny cams. Even
simply sending emails with attachments. That increases latency and
decreases throughput a lot, but that’s something Freenet can already
cope with to some degree: The bandwidth of nodes already varies over
several orders of magnitude.

And it’s not like the proposal is new. But it needs core support
⇒ transport plugins

I don’t intend to say “toad should do this over summer”, just “please
don’t discard it prematurely”.

Best wishes,
Arne


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] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Am Freitag, 10. April 2015, 19:51:17 schrieb Arne Babenhauserheide:
 - A HACKING guide: “For those who come after me”.
 
 - Documentation for the Plugin API which is easy to follow and answers
   the question how to create a plugin we can easily make official.
 
 - A package for Debian, maybe also for Fedora. Together those should
   cover most distros.
 
 - The ability to create bundles from the web interface which allow one
   friend to connect without further non-freenet communication.

Other large goals I forgot:

- transport plugins
- content filters

But at least the latter can be done by volunteers. And transport plugins
are pretty huge.

On IRC toad said “maybe have an at-least-50%-uservisible rule”, and I
think that would be a good rule of thumb.

I would add “only a released feature is a finished feature”. So for
every step, there should be a release including it.

Best wishes,
Arne


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] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Am Samstag, 11. April 2015, 01:53:22 schrieb Matthew Toseland:
 The latter might be fixed by good javadocs on BaseManifestPutter and its
 inner classes. The site insert code is pretty arcane.

I think it would be easier to find in general documentation about
insert code, with simply a link to that in the javadoc. That’s then
also something we can show new people: “this is how our inserts work”.

I’m not opposed to JavaDoc. Use it where it helps. But it’s not a goal
in itself, just one of many tools to achieve the goal of making it
easier to work with Freenet.

Best wishes,
Arne


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] [RFC] Freenet Summer of Toad

[Matthew Toseland]

On 11/04/15 09:57, Arne Babenhauserheide wrote:
 Am Samstag, 11. April 2015, 01:53:22 schrieb Matthew Toseland:
 The latter might be fixed by good javadocs on BaseManifestPutter and its
 inner classes. The site insert code is pretty arcane.
 I think it would be easier to find in general documentation about
 insert code, with simply a link to that in the javadoc. That’s then
 also something we can show new people: “this is how our inserts work”.
No, this is *site inserts*. As I said, that code is pretty arcane, and I
didn't write it (Saces did). It needs to be explained largely at the
class level IMHO, because any other kind of inserts works differently.
 I’m not opposed to JavaDoc. Use it where it helps. But it’s not a goal
 in itself, just one of many tools to achieve the goal of making it
 easier to work with Freenet.
Right. This particular example is only relevant to the handful of
classes involved in site inserts. One way to deal with it would be
detailed class-level explanations.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] [RFC] Freenet Summer of Toad

[Matthew Toseland]

On 11/04/15 09:52, Arne Babenhauserheide wrote:
 Am Samstag, 11. April 2015, 01:34:17 schrieb Matthew Toseland:
 Transport plugins are written by a GSoC student (Chetan), but need major
 refactoring and fixing of concurrency issues (plus implementing
 stream/TCP plugins)
 How much work would it be if you left out stream stuff? 
A lot. And risky technically, even though it's mostly written already.
Difficult to estimate how long it would take to make it work well and
clean it up. Especially as breaking it into manageable chunks would
probably mean losing authorship information! But the biggest problem is
it would be very hard to break it into manageable chunks for merging.
 If we have
 packet-based transports, plugins should be able to handle the
 transformation to and from TCP, so first doing only packet-based
 transports would give the capabilities to do more.
Yes, but the whole idea of transport plugins is to make life easy for
people implementing them, do all the hard stuff in fred itself, so we
can have lots of them.
 Traffic flow analysis is cheap nowadays, and no amount of stego can
 get us away from that.
 We could simulate full traffic profiles: capture the traffic between
 applications, then fake it. Video telephony, static noise on a mumble
 chat (using an intermediate server for spreading it), bunny cams. Even
 simply sending emails with attachments. That increases latency and
 decreases throughput a lot, but that’s something Freenet can already
 cope with to some degree: The bandwidth of nodes already varies over
 several orders of magnitude.
Freenet needs real-time transports at the moment. Persistent requests
would be another huge feature, and there are major unsolved technical
issues such as how to assign locations. And most useful setups would
*still* be detectable via traffic flow analysis. In its more advanced
form this consists of getting routers to export {source, dest, start,
end, bytes} tuples and then analyzing them on some central computer.
 And it’s not like the proposal is new. But it needs core support
 ⇒ transport plugins

 I don’t intend to say “toad should do this over summer”, just “please
 don’t discard it prematurely”.

 Best wishes,
 Arne



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Am Freitag, 10. April 2015, 06:22:50 schrieb xor:
> On Thursday, April 09, 2015 09:27:32 PM Steve Dougherty wrote:
> > What would we want to direct this development time toward? My opinion is
> > that more code / features is not what Fred needs most right now.
> 
> Full ACK on not having him work on features.
> Semi-Non-ACK on what you suggested he should do, in-depth explanation below.
> First here's my idea what he should do:
> 1. Write package-info JavaDoc for all packages (I think he actually did that 
… 
> 5. Write generic documentation and tutorials on the Wiki.

I think that this would be a waste of time, except for the 5th point.

I know that “waste of time” sounds extreme. I say it in such strong
words, because whenever I did something in Fred, it wasn’t lack of
JavaDoc which slowed me down. And for the subset of the code I saw, I
could write JavaDoc myself with a little investigation, so we do not
need toad for this.

What slowed me down was the lack of practical, high level
documentation. Examples:

- How to write a plugin which does anything remotely useful?¹
- What callbacks are triggered when I request a key? And where do they run?²
- Ĥow do Toadlets work? (turns out that that isn’t that complex after all)

¹: See my try at writing a plugin tutorial, putting it off halfway
   because it was getting unbearable: https://d6.gnutella2.info/freenet/USK at 
xqbzQkEGFnFfZH3LG~ut8bjV51o~3nrIXMN3ld5Qjs0,SThdqkHICKxLZvKzMcfK4w04Y4ykcE1~lmQiskpsVqw,AQACAAE/freenet-plugin-bare/5/

²: What does a PutHandler do, where is it fired and why is there a 
JokerPutHandler?
https://github.com/freenet/fred/blob/c314c517e421b683f6676b109b95145151da22fc/src/freenet/client/async/BaseManifestPutter.java#L329

These issues aren’t fixed by JavaDoc.

They are fixed by a Hacking Guide: “For those who come after me.”

At the same time there are quite a few things which only toad can do
efficiently, because only he knows the code well enough to anticipate
the side effects of the changes, or where they have to be wired in.

Note that documenting the API is something completely different than
just throwing in JavaDoc. The FCPv2 documentation in the Wiki is an
example of documentation which works: Whenever I did something with
pyFreenet, that documentation helped enormously.

Something like that for the Plugin API. Maybe focussed to answer the
question “How to write a plugin in such a way that it can easily be
made official?”


I like the idea of packaging. In addition I’d like to see the darknet
invitation bundles become reality. It’s not hard, it’s just complex
and touches lots of parts of fred. We need bundles for multiple
platforms which include one or several noderefs. We need one-time
tokens to avoid requiring an initial noderef exchange, we need darknet
FOAF routing. All this has been planned in detail in the
bugtracker. And it can be done in small, self-contained steps which I
would think that toad can do over summer.

Packaging makes opennet easier: apt-get cannot give you darknet
references. That’s useful, because it can give us many more users, and
it makes it easy for developers to use Freenet as communication
backend: Just add a dependency when you package your program.


Together this would give tangible deliverables:

- A HACKING guide: “For those who come after me”.

- Documentation for the Plugin API which is easy to follow and answers
  the question how to create a plugin we can easily make official.

- A package for Debian, maybe also for Fedora. Together those should
  cover most distros.

- The ability to create bundles from the web interface which allow one
  friend to connect without further non-freenet communication.


3 weeks each would give solid 12 weeks of full-time work.

Best wishes,
Arne
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 299 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] [RFC] Freenet Summer of Toad

[Arne Babenhauserheide]

Since it’s relevant: There are still 2.5k€ in my account from SUMA
which I want to send to Ian. That they aren’t there yet is completely
due to me being slow talking to my bank and then sending Ian a mail
with the data I need from him to send the money.

Best wishes,
Arne

Am Donnerstag, 9. April 2015, 21:27:32 schrieb Steve Dougherty:
> Google Summer of Code didn't work out for us, but maybe we can have a
> Freenet Summer of Toad? It's not certain yet, but Matthew might be
> interested in working 35-hour weeks over the summer for FPI. He says he
> wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
> this while maintaining current operations will require a fundraiser. Are
> people interested in doing this?
> 
> If we go through with it we'd put a fundraising bar on the website and
> count subsequent donations toward it. It might be good to have a mark
> both at $6k as the minimum and $10k as the entire summer.
> 
> Last summer purge-db4o coming into review all at once was a formative
> experience for the community. We've agreed that development must now be
> put up for review and merged in much, much smaller pull requests along
> the way.
> 
> What would we want to direct this development time toward? My opinion is
> that more code / features is not what Fred needs most right now. I'd
> like to ask that Matthew document plugin APIs and work on packaging:
> things like splitting freenet-ext, making a Debian / Ubuntu package, and
> maybe even creating an official distro package repo in Freenet. This is
> because for those utilities that already exist, Freenet is pretty
> effective, but I have seen many developers give up when they see the
> lack of documentation, and the lack of packages makes it harder to
> install and harder to depend on. There are unofficial packages for Arch
> and Gentoo, and freenet-ext being monolithic makes packaging Freenet harder.
> 
> Documenting the API will also make it clear what is considered API, and
> reviewing it can then suggest improvements. If documentation is
> completed it could get as far as developing improvements to the plugin
> API. It is mandatory that any changes be backwards-compatible.
> 
> Thoughts?
> 
> - Steve
> 

-- 
Unpolitisch sein
heißt politisch sein, 
ohne es zu merken. 
- Arne (http://draketo.de)


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 299 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] [RFC] Freenet Summer of Toad

[Luke]

On 04/09/2015 09:27 PM, Steve Dougherty wrote:
> Google Summer of Code didn't work out for us, but maybe we can have a
> Freenet Summer of Toad? It's not certain yet, but Matthew might be
> interested in working 35-hour weeks over the summer for FPI. He says he
> wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
> this while maintaining current operations will require a fundraiser. Are
> people interested in doing this?

Fundraising is good, but re-occuring fundraising is better for the long
term. You could try to use GratiPay or Patreon. I know of a few
opensource projects that have had success with this.

As far as critical areas of work, documentation should be #1 since it's
totally confusing to new comers. Secondly however, I'd like to see some
official implementation of transport plugins. Firewalls have already
figured out how to completely block freenet otherwise.


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: 

[freenet-dev] [RFC] Freenet Summer of Toad

[xor]

On Friday, April 10, 2015 06:22:50 AM xor wrote:
> > and work on packaging:
> > things like splitting freenet-ext, making a Debian / Ubuntu package, and
> > maybe even creating an official distro package repo in Freenet. This is
> > because for those utilities that already exist, Freenet is pretty
> > effective, but I have seen many developers give up when they see the
> > lack of documentation, and the lack of packages makes it harder to
> > install and harder to depend on. There are unofficial packages for Arch
> > and Gentoo, and freenet-ext being monolithic makes packaging Freenet
> > harder.
> Hmmm. I actually do agree that it might be a very good idea to finally
> resolve the situation of not having Debian packages.
> Personally, when looking for software for my Linux workstation, I have the
> following rule: "If something is not packaged, I will use something else. If
> people don't even bother to package software, it must suck."
> 
> :(
> 
> I think there is a high probability that this is the general behavior of
> Linux users :(  Package-management is such a nice concept and great
> advantage of these operating systems.
> And most potential Freenet developers are probably Linux users: We have for
> a long time not even had a proper Windows installer because everyone was on
> Linux.
> 
> However, it will not magically solve the documentation problem, and thus
> should be deferred. We should really first quit having a truck number of 1.
> 

Doh, I proof-read my mail thrice, yet it still took only 3 seconds after I 
sent it until a better way of saying the above came to my mind - sorry:

Working on packaging aims to attract more new developers.
However, there is no use in attracting developers if after we have caught 
their attention they then cannot actually work on the code because it is 
undocumented.
Thus, documentation should be done *before* stirring up attention by packaging 
:)

Maybe it might make sense to combine my "20% of the time for packaging" 
proposal with sticking packaging somewhere in the sequential order I had 
proposed for documentation:

> Considering that it is very difficult to say how long documenting everything
> will take, his work should be like an onion to allow some progress
> everywhere - first high level documentation, then low level, until time
> runs out. I suggest the following order, sorted descending from high to low
> level: 1. Write package-info JavaDoc for all packages (I think he actually
> did that already before he left for the first time)
> 2. Write class-level JavaDoc for all classes.
> 3. Write JavaDoc for all member variables of classes.
> 4. Write JavaDoc for all functions.
> 5. Write generic documentation and tutorials on the Wiki.

How about this:
After step 2 is finished, 40% of toad's time could be used on packaging in 
parallel to the remaining documentation steps.

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] [RFC] Freenet Summer of Toad

[xor]

On Thursday, April 09, 2015 09:27:32 PM Steve Dougherty wrote:
> Google Summer of Code didn't work out for us, but maybe we can have a
> Freenet Summer of Toad?

Toad should be always welcome! :)

> If we go through with it we'd put a fundraising bar on the website and
> count subsequent donations toward it.

I highly appreciate the concept of a fundraising progress bar, similar to what 
Wikipedia does - good idea!
Once we have this implemented, we can and should also use it once every year 
then.

> What would we want to direct this development time toward? My opinion is
> that more code / features is not what Fred needs most right now.

Full ACK on not having him work on features.
Semi-Non-ACK on what you suggested he should do, in-depth explanation below.
First here's my idea what he should do:

It seems to me that toad is still uncertain about what happens after his 
studies = whether he wants to continue his work for Freenet then. (Please 
correct me if I'm wrong!!).
So the #1 effort while he can still do some work in his summer vacation should 
be to make it possible for someone else to continue his work if he really does 
leave (which I strongly hope he does not!).

Thus, the primary goal should be to fully document the existing code he wrote.
Practically speaking, I would say we do this:
Considering that it is very difficult to say how long documenting everything 
will take, his work should be like an onion to allow some progress everywhere 
- first high level documentation, then low level, until time runs out.
I suggest the following order, sorted descending from high to low level:
1. Write package-info JavaDoc for all packages (I think he actually did that 
already before he left for the first time)
2. Write class-level JavaDoc for all classes.
3. Write JavaDoc for all member variables of classes.
4. Write JavaDoc for all functions.
5. Write generic documentation and tutorials on the Wiki.

Now I know that *full* JavaDoc for every class, member variable and function 
does sound quite extreme.
But don't forget what we are: A mostly volunteer-driven project. Volunteers 
may come and go as they please, and they in fact do that very frequently, and 
thus such projects have the highest throughput of programmers in the whole 
industry.

Therefore, full documentation should be mandatory to make it as easy as 
possible for new volunteers.

(Notice: I am already trying to obey this at WOT and my fred pull requests as 
well. Feel free to notice me during review if anything is lacking JavaDoc)

> I'd
> like to ask that Matthew document plugin APIs

I think you seem to be somewhat biased to plugin stuff.
I think he should just document everything :) :|
- As a plugin author, I can say that most work lies within plugins themselves, 
not within their interaction with fred.
What fred does is highly complex, but what it spits out (= what plugins use) 
is simple: You request a key, it gives you a file. It isn't that difficult to 
understand.
The stuff fred does under the hood however *is* very complex:
Due to my recent work, I've counted all classes which are involved in 
fetching/inserting files, and they're at least 28 IIRC. And this is just the 
stuff which represents a file request/insert, not the stuff which deals with 
splitting files into chunks, adding redundancy, etc.
And then there's also the whole universe of how Freenet itself, i.e. routing 
etc., works. Plugins are not involved at all in that, yet it is important to 
be documented for fred development to be possible.

> and work on packaging:
> things like splitting freenet-ext, making a Debian / Ubuntu package, and
> maybe even creating an official distro package repo in Freenet. This is
> because for those utilities that already exist, Freenet is pretty
> effective, but I have seen many developers give up when they see the
> lack of documentation, and the lack of packages makes it harder to
> install and harder to depend on. There are unofficial packages for Arch
> and Gentoo, and freenet-ext being monolithic makes packaging Freenet harder.

Hmmm. I actually do agree that it might be a very good idea to finally resolve 
the situation of not having Debian packages.
Personally, when looking for software for my Linux workstation, I have the 
following rule: "If something is not packaged, I will use something else. If 
people don't even bother to package software, it must suck."
:(
I think there is a high probability that this is the general behavior of Linux 
users :(  Package-management is such a nice concept and great advantage of 
these operating systems.
And most potential Freenet developers are probably Linux users: We have for a 
long time not even had a proper Windows installer because everyone was on 
Linux.

However, it will not magically solve the documentation problem, and thus 
should be deferred. We should really first quit having a truck number of 1.

Is someone else maybe willing to deal with part of what you suggested here?
If not, I 

Re: [freenet-dev] [RFC] Freenet Summer of Toad

[Matthew Toseland]

On 10/04/15 14:29, Luke wrote:
 On 04/09/2015 09:27 PM, Steve Dougherty wrote:
 Google Summer of Code didn't work out for us, but maybe we can have a
 Freenet Summer of Toad? It's not certain yet, but Matthew might be
 interested in working 35-hour weeks over the summer for FPI. He says he
 wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
 this while maintaining current operations will require a fundraiser. Are
 people interested in doing this?
 Fundraising is good, but re-occuring fundraising is better for the long
 term. You could try to use GratiPay or Patreon. I know of a few
 opensource projects that have had success with this.
Re GratiPay, for years, every time we tried a payment method other than
Paypal, nobody used it. But maybe times have changed. Certainly people
have used Bitcoin.

People have suggested Flattr. I don't think it was deployed. Where would
it go? It might well distract attention from things that produce more
income.

Re Patreon, it's worth looking at Kickstarter-type stuff, but it means
writing a pitch, probably a video, and ideally having goodies to give
people. It also means finding a suitable host that allows OSS projects
and things that arguably resemble social networks (i.e. not
Kickstarter). And if it's going to be a regular event, we need to repeat
that every year with a different project. Currently we do not have the
resources to produce a video, and we don't have much in the way of
unique goodies to give away (we do have a shop).
 As far as critical areas of work, documentation should be #1 since it's
 totally confusing to new comers. Secondly however, I'd like to see some
 official implementation of transport plugins. Firewalls have already
 figured out how to completely block freenet otherwise.
Transport plugins are written by a GSoC student (Chetan), but need major
refactoring and fixing of concurrency issues (plus implementing
stream/TCP plugins), and touch a huge amount of fred code. So it'd be
another code bomb. This is probably not what we need at the moment given
the problems we've had with getting last summer's work deployed, and
then with Xor's changes to FCP! Granted I might be able to break it into
a series of pull requests, but it would still be very invasive...

The more serious point is that a determined ISP will always be able to
block Freenet, period. Traffic flow analysis is cheap nowadays, and no
amount of stego can get us away from that. Unblockability is dead.
Sorry, but that's the way it is, and has been for some time. On the
upside, if we accept that, we can implement pretty impressive anonymity
on darknet using published algorithms.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] [RFC] Freenet Summer of Toad

[Matthew Toseland]

On 10/04/15 02:27, Steve Dougherty wrote:
 Google Summer of Code didn't work out for us, but maybe we can have a
 Freenet Summer of Toad? It's not certain yet, but Matthew might be
 interested in working 35-hour weeks over the summer for FPI. He says he
 wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
 this while maintaining current operations will require a fundraiser. Are
 people interested in doing this?

 If we go through with it we'd put a fundraising bar on the website and
 count subsequent donations toward it. It might be good to have a mark
 both at $6k as the minimum and $10k as the entire summer.

 Last summer purge-db4o coming into review all at once was a formative
 experience for the community. We've agreed that development must now be
 put up for review and merged in much, much smaller pull requests along
 the way.

 What would we want to direct this development time toward? My opinion is
 that more code / features is not what Fred needs most right now. I'd
 like to ask that Matthew document plugin APIs and work on packaging:
 things like splitting freenet-ext, making a Debian / Ubuntu package, and
 maybe even creating an official distro package repo in Freenet. This is
 because for those utilities that already exist, Freenet is pretty
 effective, but I have seen many developers give up when they see the
 lack of documentation, and the lack of packages makes it harder to
 install and harder to depend on. There are unofficial packages for Arch
 and Gentoo, and freenet-ext being monolithic makes packaging Freenet harder.

 Documenting the API will also make it clear what is considered API, and
 reviewing it can then suggest improvements. If documentation is
 completed it could get as far as developing improvements to the plugin
 API. It is mandatory that any changes be backwards-compatible.
This all sounds like useful stuff. However it may be difficult to
fundraise for as it's not user visible.

Also, plugins and packaging are largely areas that I have the least
experience of / have tended to delegate. Which is fine, I'm sure I can
dig up everything needed. But it's something to take into account. I
don't anticipate finishing the debian package taking all that long,
although it depends on how far out of date it is, and whether we aim for
inclusion in experimental (but not with a view to inclusion in stable).
Finding acceptable solutions for the components that generally get built
via Maven is important both for packaging and for updating/splitting
freenet-ext.jar (if that is indeed a priority); if we're going for
inclusion, there will be distro-specific standards about that.

Re documentation, I agree with everyone: Package, class, etc are
important, but so are higher level guides. I believe I can write
effectively when I put the effort/time in, and ArneBab's work may be a
good start. Also unit tests are a form of communication IMHO, so worth
thinking about.

And I'm sure you all know I love darknet. There are lots of useful
feature ideas on the bug tracker, and I suspect we need to have
something user-visible to show for my summer's work. Stuff like the
darknet enhancements can be easily divided up into smallish pull
requests. Having said that if we want to credibly raise funds we may
need to be more explicit, e.g. I should spend half my time on cleanups
and documentation and the other half on user-visible improvements
(darknet improvements, bug fixes, packaging, whatever).

Also I'm happy to be involved in code review; there is stuff we still
haven't merged from years ago, e.g. filters, much of it blocked on the
Maven issues mentioned above. Would need to liaise with Steve, but I'm
happy to take some of the load if he thinks it makes sense.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] [RFC] Freenet Summer of Toad

[Steve Dougherty]

Google Summer of Code didn't work out for us, but maybe we can have a
Freenet Summer of Toad? It's not certain yet, but Matthew might be
interested in working 35-hour weeks over the summer for FPI. He says he
wants at least $6k for 8 weeks but preferably $10k for 12 weeks. Paying
this while maintaining current operations will require a fundraiser. Are
people interested in doing this?

If we go through with it we'd put a fundraising bar on the website and
count subsequent donations toward it. It might be good to have a mark
both at $6k as the minimum and $10k as the entire summer.

Last summer purge-db4o coming into review all at once was a formative
experience for the community. We've agreed that development must now be
put up for review and merged in much, much smaller pull requests along
the way.

What would we want to direct this development time toward? My opinion is
that more code / features is not what Fred needs most right now. I'd
like to ask that Matthew document plugin APIs and work on packaging:
things like splitting freenet-ext, making a Debian / Ubuntu package, and
maybe even creating an official distro package repo in Freenet. This is
because for those utilities that already exist, Freenet is pretty
effective, but I have seen many developers give up when they see the
lack of documentation, and the lack of packages makes it harder to
install and harder to depend on. There are unofficial packages for Arch
and Gentoo, and freenet-ext being monolithic makes packaging Freenet harder.

Documenting the API will also make it clear what is considered API, and
reviewing it can then suggest improvements. If documentation is
completed it could get as far as developing improvements to the plugin
API. It is mandatory that any changes be backwards-compatible.

Thoughts?

- Steve

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: