* Magnus Eriksson <magetoo at fastmail.fm> [2006-07-12 14:58:24]:
> On Wed, 12 Jul 2006, Florent Daigni?re (NextGen$) wrote:
>
> >>>That's why I had suggested some form of updates-only protocol that could
> >>>be long-lived.
>
> >> Or in other words, "some form of new attack vector that could be hard to
> >>fix".
>
> >No, some protocol changes, that's all.
>
> Implementing a brand new protocol is "some changes" ?
>
> You're probably talking about update-over-mandatory (or whatever it will
> be called). Fine. How do you intend to make sure only updates (and no
> other requests) are passed to "old" nodes? It looks to me like some sort
> of new protocol would be needed. And that might have security
> implications, which was my point.
We don't need a new protocol, we have a message
dispatcher/mangler/whatever and we can ask it to handle only some "safe"
messages when build numbers are incompatible.
see what I've just commited in r9573 : it allows "incompatible" builds
to exchange node to node text messages. The same sort of things will be
used to allow over-mandatory updates.
>
> Or, we hope the users take care to update their nodes often enough, and
> the network doesn't fall apart. Obviously not everyone will update "on
> time".
>
> If, on the other hand, the network really *won't* be able to handle a
> situation where some percentage of users aren't running the very latest
> build, then I'm going to have some serious doubts about those claims about
> being useful under "hostile regimes".
>
>
> >> Face it. Either the network is good enough (and robust enough) to allow
> >>people to get their updates through the network itself, or it isn't. And
> >>if the developers don't trust the network enough to even distribute
> >>updates to the software, why should I as a user even bother?
>
> >We are already doing it...
> >The problem with mandatory releases is that as soon a node has fetched the
> >full update, it WILL update and won't talk to older builds... thereby the
> >content won't spread.
>
> That looks like a rather obvious problem. How will you solve it?
At the moment we are using a trivial solution : we "time-bomb" mandatory
updates ; Meaning that newer builds will talk to old builds for some
days before denying them access.
They are two problems with that :
1) some boxes aren't on time
2) some people aren't running their node for a few days and will
miss the "auto-update window"
>
> >> The fact that this is even an issue (and that the mandatory builds are
> >>so common) should be a cause for any potential user to think twice if
> >>this, that is, Freenet, really is the way to go.
>
> >Freenet is still in alpha stage ... Should we slow down the development
> >process on the behalf that some users aren't willing to update ?
>
> What you should do is decide whether you're twiddling with the details
> in your own lab or actually developing an end-user ready network. It
> seems like someone is trying to both have the cake (making incompatible
> protocol changes, frequent mandatory builds) and eat it (complaining over
> lack of content, asking for donations).
>
I'm not developing an end-user ready network, that's why it's called
alpha.
And I'm hardly ever complaining about the lack of content : I do know
that it's not end-users who are inserting content. Content inserters are
power users and they are more likely to understand that we need frequent
updates and they will keep their node up to date, report bugs, insert
content, limit the networking churn ; They are usefull, end-users are
simply not helpfull until we leave the alpha stage.
That doesn't mean we shouldn't do some efforts toward easing the use of
freenet.
> >>Some sort of disclosure: I do not currently use Freenet. [...]
>
> >Then install it and you'll see that the update-over-freenet mechanism
> >performs well. Updating over mandatory builds isn't implemented yet,
> >that's all.
>
> Installing it means a major OS upgrade for me, so I think I'll hold off
> until it seems more stable / useful.
>
huh ? how can running a java program require an OS upgrade ? :)
>
> Sorry if I'm being a pain in the ass, but IMHO I'm only asking pretty
> obvious questions that you'll have to deal with sooner or later anyway.
>
>
>
> MAgnus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20060712/3fb96632/attachment.pgp>