Re: [GNUnet-developers] Re: Other way to updateable content

[Igor Wronsky]

On Thu, 30 Jan 2003, Tom Barnes-Lawrence wrote:

> So, whilst earlier, the archive part of the list had seemed to
> be screwed up, now it seems that the mailing part is!

A hearty kick would be in order to whoever is responsible
for that sad excuse for a mailing list archive software/
hardware -combination...

>  I didn't worry  at first, but after reading Christian's points on
> the matter, I feel inclined to agree with him. My worry (probably
> wrong) is that nodes created by evil people could trivially
> throw away the special blocks that have a serial# greater than
> 1, thus increasing the probability that someone requesting the
> item would end up with just the first version.

Of course they can throw them away. And it wouldn't be much additional
difficulty to throw away anything inserted by a known pseudonym
(=="someone dealing in no-good content"), no matter which of the
namespace schemes is used. And it beats me why a node would want
to discard something that is from an unknown pseudonym: the discarding
will never help node to gain credit, and neither will the forwarding
of old blocks, if the user requests a newer one. And once she gets
just a single correct block, no matter how old, she can instantly
start requesting a newer one, as I've argumented. So I don't
see any new evidence coming to light here. Of course a node
can be disruptive to the network by refusing to traffic in
serialized rootblocks except 1, but as long as the majority
is behaving ok, it should suffice. If the majority does not
behave, I don't know how reasonable guarantees gnunet could
offer anyway.

> In fact, I take it that if the block that points to the
> content is found by a reference that involves a recent date,
> presumably a client (either one of the normal download clients
> or some separate utility type client) could be made to search
> for specific older versions, and even compile such an archive
> (ie- find a reference for every existing version of the content)
> in order to encourage this, and to help out people who can't
> find the version that should be available.

The namespace proposal - if I remember correctly <grin> -
already contains such an option that enables users to publish
'editions' such that each has some id (encrypted) and that
are not overwritable. The problem here is that greater-than
queries can not be supported. I'd like to see (but its unlikely
that such would be forthcoming soon) some sort of analysis
showing how much the overwriting scheme gains by overwriting.
On a quick thought, the trivial gains are that old entry
points will be replaced, slightly reducing the used space
and lessening the amount of transferring and querying for
obsoleted data.

> to be a bit unconvinced of the idea, but at the same time,
> so am I- or at least, the fproxy+HTML part of it.

There's no immediate fear that I would be attempting to
code either of them, or their combination, or any scheme
containing the word 'rendering' in it, as I've said. ;) If you
wish to specify a GNML or use gopher or something less-expressive
than html (and probably obsoleted) for such purpose, I don't
have anything against it, but I don't most likely either have time
or patience to participate it. While in theory I see communities
and hyperlinked content really nice, and I see their
value in attracting users, I'm much more concerned of
gnunets ability to do the very basics: allow anonymous
filesharing in a manner that scales, is usable in practice,
and efficient. This may not reflect the stated goals of
the gnunet project, but without such there's no need
for bells and whistles, or 'universum over gnunet' -schemes,
if it can't be used in practice. Each time I see gnunet lookup datastore
getting inconsistent, node losing its connections for no reason,
obscure log entries a galore etc etc, I grind my teeth and wish that
we could deliver the basics solidly. And unfortunately that doesn't
seem to be easy. Other p2p projects, such as freenet or edonkey
variants (basic,overnet,mldonkey) are still suffering from
annoying faults in their core functionality, and many of them
have been around longer.

This whining may sound silly and unconstructive, but for
every fault that has turned from obscurity and denial ("no,
there's nothing wrong with it") to a recognized bug and
then fix, a new problem has succeeded in coming up. :(

Uh, a lenghty explanation, but it has a reason: as much
as I dislike it, I rather spend the little patience I
have in getting over the current problems instead of
running to implement new ones. ;)

> interested in that until very recently (sorry, sorry. I just
> find your namespace doc a bit hard to read. Like a sed script ;).

Well, it might require a bit of expanding, as does a lot of
gnunet documentation anyway. It seems mostly to be written
for some technically aware archeologists excavating some
ruins instead of current public (of course it could've been
written for technically aware coders interested to take part in
gnunet development right now, but they seem to keep awfully quiet,
and enables me to question their existence in the present time,
or atleast those wanting to fix the core operation I don't
hear about often... hehe, with less documentation the freenet
project has much more eager beavers there).

> I'm now committing myself to
> producing some client-side stuff for GNUnet,
> depend on what I find I'm able to produce! I've got hopes and
> ideas, but they may change in the cold light of day.

See how nicely I've tried my best to blow away the
optimistic vapours of your nocturnal fumings... ;) But
more seriously, all useful clientside stuff is
of course appreciated.

>  -The client-side stuff shouldn't require nearly as much familiarity
>   with gnunet (either it's design or it's source) as the server-side
>   stuff, so it makes great sense for those who understand gnunet
>   the best (like you guys) to be focusing on the server and deciding
>   on those important design issues (like the Namespace system) whilst
>   the lowly grunts (such as myself) do the less critical client bits.

Agreed. But "us guys" are not gods either, and personally I understand
gnunet much less than I should, and would happily see new people
in the core devel group.

>  -I kind of hope to convince you of not exactly going the fproxy way,
>   and one possible way of doing so is by showing the alternative!
>   Either I can show something that's convincing of my point, or I
>   can maybe show my ability and/or resolve, to write such a thing.

Just let us know what you come up with.


Igor