gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Barnes-Lawrence
Subject: [GNUnet-developers] Re: Other way to updateable content
Date: Thu, 30 Jan 2003 05:47:04 +0000
User-agent: Mutt/1.3.28i

 To start with, I feel I ought to point out:
Christian wrote a reply to this email (of Igor's), which I
received from the list.
Then, I got another email from Igor, that was an identical
copy of the email quoted below (so I now have 2 copies of that
email, from separate days). Yet the mailing list archive
shows a whole new email from Igor in response to Christian's
one.
I seem to have no more emails from the list since then, but
there is now another response from Christian on the archive now.

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

OR, perhaps it's just my email account- but I'm still getting
email from my friends, etc.

On Sun, Jan 26, 2003 at 06:31:18PM +0200, Igor Wronsky wrote:
> Ok, while taking a shower I came up with a simpler scheme for
> allowing updateable content. Some of you will probably scream
> "noo!!!!", but please read my whole argument.

 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. If dealing with an
organisation with large resources, this could maybe add up
to a significant effect.  Or, maybe it wouldn't.

 Yet at the same time, it is a point that the previously proposed
mechanism of "updatable content by having a new version for
every week/month/whatever", does *seem* a bit unsatisfactory-
not just that it might be onerous to have to reinsert the content
at regular intervals, but more importantly, what if the author
gets ill, or goes on holiday, or is extremely busy with something?

 What if a piano falls on them? Furthermore, if an organisation
couldn't censor someone's content, but had a vague suspicion who
was responsible for putting it up*, they might be able to stick
them in prison for something or other, and "poof!" it would
vanish...

...*except* that as it has been pointed out, people could still
make direct references of their own to the existing content, and
so could even make an archive if they got all of the references
for each version.
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.


> ps. Christian, you sounded mildly sceptical of the fproxy
> issue. However, such a scheme is quite popular in freenet,
> and gives it atleast some community feeling. If gnunet
> can be competitive with freenet in transferring raw
> data, there is no reason why the fproxy wouldn't work
> as good or better in gnunet env.

  Igor, I'm not 100% sure whether you really were referring to
Christian's ideas or confusing them with mine. He does seem
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.
 I do agree with you on the idea of the networked community
feeling, which was the sort of thing I'd been so taken with in
trying to push my GNML suggestion. I hadn't realised you'd been
interested in that until very recently (sorry, sorry. I just
find your namespace doc a bit hard to read. Like a sed script ;).

  Anyways. I know that even if I were more authoritative (or
whatever) in this project, I would still have no right whatsoever
to tell you what to do. So please don't take this as me trying
to boss people about, it's just a polite request:
 If you're looking at the idea of actually implementing an
fproxy type system (which IMHO would not be a good thing), could
you *at least* not do it yet? I'm now committing myself to
producing some client-side stuff for GNUnet, and intend to have
something to show for my efforts within a fortnight (That's
2 weeks, as someone once asked me what it meant. shrug). I
should at least have a progress report, and some alpha-level
code. Of some sort.

 Exactly what the client-side stuff I produce will be, will
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. But the
main reasons for my request are:

 -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.

 -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.

 I hope you don't consider me too pushy in asking that. I really don't
want to cause offence.

Tom Barnes-Lawrence




reply via email to

[Prev in Thread] Current Thread [Next in Thread]