[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] Freenet math
Just for archived easy reference:
mathematical reasoning about freenet (digest mode)
------- Forwarded Message
To: freenet-chat@lists.sourceforge.net
Reply-To: freenet-chat@lists.sourceforge.net
Sender: freenet-chat-admin@lists.sourceforge.net
Errors-To: freenet-chat-admin@lists.sourceforge.net
Send Freenet-chat mailing list submissions to
freenet-chat@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Freenet-chat digest..."
Today's Topics:
1. Mathematical Reasoning about Searching Freenet (Alex Barnell)
2. Re: Abusing Searches (Alex Barnell)
3. Re: metadata makes clients usable (Alex Barnell)
4. Re: A proposal - Hierarchial permissions and chaining
data (Ian Clarke)
5. Re: Logo Proposal (Mikus 29)
6. Re: Logo proposal (Mikus 29)
7. Re: Mathematical Reasoning about Searching Freenet (hal@finney.org)
8. Re: Mathematical Reasoning about Searching Freenet (Alex Barnell)
9. Re: Logo Proposal (Marcel Popescu)
10. RE: Napster orders Offspring to stop pirating the
Napster logo (Stover, Michael)
11. Re: Mathematical Reasoning about Searching Freenet (Pierre Abbat)
- --__--__--
Message: 1
Date: Thu, 08 Jun 2000 12:38:29 +0100
From: Alex Barnell <aeb99@doc.ic.ac.uk>
To: freenet-chat@lists.sourceforge.net
Subject: [Freenet-chat] Mathematical Reasoning about Searching Freenet
Reply-To: freenet-chat@lists.sourceforge.net
(This is on the web at http://www.doc.ic.ac.uk/~aeb99/fnsearch.txt)
Mathematical Reasoning about Searching Freenet
==============================================
Outline
- -------
1. For an efficient searching mechanism, Metadata must cluster in some
way
2. For an arbitary type to cluster, there must be some valid closeness
relationship defined between any three instances of that type
3. For three entities to have a valid closeness relationship between
them,
they must all have the same cardinality (or dimension)
Conclusion: Any efficient searching mechanism must limit any closeness
comparisons between Metadata to Metadata with the same cardinality.
A solution to searching is at the end, that satisfies the above
condition.
The Mathematics of Closeness
- ----------------------------
The cornerstone of Freenet is closeness. This has been defined as a
relation between three entities A, B and C which asserts that
"A is closer to B than it is to C"
Closeness is what allows Freenet to route requests and inserts for keys
intelligently, due to the clustering effect. This much is generally
understood, although we do not yet have a proof.
(Side-note: I think a proof that clustering will occur under any user
behaviour is possible. It may be based on the fact that for any
particular
request, the data that falls off DataStores is probably less valuable to
clustering that the data that is replacing it.)
Currently, the keys that we use can be thought of as types with a
cardinality of one (i.e. a key is a member of the Set corresponding to
keyspace. Set and type can be used interchangably)
e.g.
KHK=60207CB2 |KHK| = 1
or CHK=57DG28A1 |CHK| = 1
or SVK=C95FD3F0 |SVK| = 1
We could use types of a different cardinality for keys. For example,
if we imagine our entire keyspace to lie on a piece of paper, we could
use
two-dimensional cartesian co-ordinates to define any key in that
keyspace:
Key A:
x = 1 |A| = 2
y = 4
Key B:
x = 3 |B| = 2
y = 5
Key C:
x = 20 |C| = 2
y = 42
Each key here has a cardinality of 2. It is obvious that key A is closer
to
B than it is to C. Use Pythagoras' theorem if you aren't convinced.
The same applies in three dimensions. Or four. Or however many you want.
We
can use Pythahoras' theorem again to determine the distance between any
two
entities in n-dimensional space:
dist(A,B) = sqrt((b1-a1)^2 + (b2-a2)^2 + (b3-a3)^2 ... + (bn-an)^2)
where: dist(A,B) is the distance between A and B
xn is the value of the nth dimension in X.
This can be used as the basis of a closeness relationship between
entities
with the same cardinality, where the cardinality is arbitary. The
distance
equation is not restricted to numbers. It could be used for strings for
example, by simply letting the '-' operator to mean the fuzzy difference
between Strings (with obvious importance to Metadata)
Why does this work? It is because the entities we are comparing for
closeness are of the *same cardinality*. We are comparing
one-dimensional
types with other one-dimensional types. Or two-dimensional types
with other two-dimensional types.
Try picking a point in space above and to the right of your head (A),
and
two different characters on the screen in front of you (B and C). A lies
in
3D RealLife-space, whereas B and C live in 2D Cyberspace.
(Do it - this is a crucial analogy to Metadata comparisons)
Now tell me, is A closer to B or C?
You may say "Well it's obvious.. I can work out the distance between A
and B,
and A and C, using a tape measure, and the one with the shorter distance
is
the closest. Hey look, it's B. A is closer to B than C."
This is cheating! You have just converted the characters in 2D
cyberspace
to 3D RL-space, instead of considering them purely in terms of the 2D
pixel
co-ordinates. To make this point more clear, you could move the screen
somewhere else (say, facing the other way), which would then change the
result of your so-called closeness relationship to make C, rather than
B,
closer to A, even though the 2D co-ordinates on screen *haven't
changed*.
The closeness relationship is obviously not valid, since it is
inconsistent.
The characters on the screen and the point above your head are in
completely
different spaces. One lies in 3D real life, the other two in 2D
cyberspace.
There is literally NO distance between them. By that I don't mean that
the
distance is zero. I mean that they are not connected at all by any path
in
any space. For this reason, no closeness relation can be defined, since
closeness depends of being able to define distances between entities.
Here lies our problem with closeness-relations on Metadata, which are
needed to route inserts and requests of Metadata. We are letting
different
Metadata be of different types, and hence *different cardinalities*.
For example:
Metadata A:
Title = Graphic Java
Author = David Geary
Publisher = The Sunsoft Press
|A| = 3
Metadata B:
Content-type = audio/mp3
Artist = Metallica
Song = We will fuck with you, evil Freenet developers
Year = 2000
Bitrate = 128KBps
|B| = 5
Metadata C:
Picture = Hopstolive the Rabbit
Author = Oskar
|C| = 2
In the example above we have three pieces of Metadata. We may like to
know
if A is closer to B than it is to C. This would occur if our node has
received
a request for Metadata matching the criteria of A, and subsequently not
found
an exact match (or not enough matches). So we have looked in our
MetaDataStore
and found B and C, and would to know whether to route the request to
either
the DataSource of B or C. We need to find if A is 'closer' to B or C.
A lies in 3D-space, B is in 5D-space, and C belongs in 2D-space. The
actual
datatypes of individual elements within metadata (Content-type, Author,
bitrate etc.) are unimportant (from the point of view of a closeness
comparison, not the point of view of a criteria-matching operation).
Re-naming
the x and y axis in 2D space to two other letters doesn't stop you
finding
distances between points does it?
All three pieces of Metadata are of different types and have different
cardinalities. We therefore cannot use the same closeness relation
algorhythm
that we use when comparing points of a piece of paper, points in 3D
space,
or hash keys in one-dimensional unicode-space.
All is not lost though..
I propose that there are at least two ways of creating a useful 3-way
closeness relation on Metadata in a system to search Freenet:
1. Limit metadata comparisons to metadata of the same cardinality.
or 2. Create a mapping between metadata of an arbirary cardinality to
a standard type with a standard cardinality.
My proof is thus:
If we can find a solution to method 1, then we can use the same
well-defined
closeness relations that we can use on any entities belonging to the
same
dimensional space (Pythoras' Theorem)
If we decide that there is no satisfactory solution to method 1, but we
find
a solution to method 2, then the consequence of method 1 is
automatically
implied, since entities of a common type share the same cardinality. QED
Solution
- --------
Method 1: Limiting Metadata comparisons to Metadata of the same
cardinality
- ---------------------------------------------------------------------------
Say we have three Metadata items: A, B and C. All have three terms, and
hence
each is of a type with a cardinality of three. We can therefore use
Pythagoras'
distance equation (defined at the start of this file) to determine
whether A
is closer to B or C. This is assuming that all terms are treated as
strings.
For consistency, each Metadata would have to be re-ordered so that the
datatypes of elements are in alphabetical order.
e.g.
Title = Graphic Java
Author = David Geary
Publisher = The Sunsoft Press
is converted to
Author = David Geary
Publisher = The Sunsoft Press
Title = Graphic Java
before any comparison is made, to avoid ambiguity (like getting the x
and y
axis the wrong way round!)
If all metadata in Freenet had three terms, and all search requests had
criteria with three conjunctions (ANDs), then routing search requests
would
be a doddle. It would be *equivalent* to the routing and clustering that
we get with KHKs, CHKs etc. We can either choose to perform fuzzy string
comparisons on just the values of the Metadata elements, or to
concatenate
the keys and values of each element to form one string to use in the
comparison (both methods would work, as long as all nodes decide on a
common system to use).
Of course, limiting all Metadata to consist of three terms would be very
inconvenient (although not entirely useless). But there is a solution
that allows for all types of Metadata to be used in both defining
Metadata
and searching upon it, whilst still limiting all comparisons to Metadata
types with identical cardinalities.
Here is the solution:
Metadata Inserting
==================
1. Because comparisons on Metadata will be limited to those with the
same cardinality (amount of Elements) as the criteria Metadata, and we
would
like Metadata to be matched without the user having to specify each of
the
original fields in the Metadata, the idea is create the Power Set of
Metadata
to be inserted (minus the Empty set), and insert each of the elements of
the
Power Set indivually. This way, we cater for every single possible
combination
of criteria matching the Metadata that a user may specify.
The power set of a set is every single possible subset of the set.
For example, if the original Metadata is:
Content-type = audio/mp3
Artist = Metallica
Song = We will fuck with you, evil Freenet developers
Year = 2000
Bitrate = 128KBps
Then there are 2^5 Metadata sets in the Power set. This can be seen,
by considering that every term may or may not choose to be in any
particular
element of the power set.
In general, for Metadata with n key/value pairs, there will be 2^n
Metadata
in it's Power Set. One of these will be the empty set, which obviously
has
no purpose in being inserted.
So we need a method to get all the elements of the Power Set inserted
into
Freenet. We would also like to include the entire original Metadata
with
each of the elements of the power set, so that nodes returning results
based
on matches on elements in the power set can be more informative about
the
metadata.
In doing this, we would like to avoid the potential discovery of
the original inserter. If the client software naively insereted each
element of the Power Set like we do now, it would be possible to tell
that they invented the data.
One solution is to create a new Insert mechanism especially for public
Metadata, where the client inserts all elements of the Powerset in one
bundle, and then each subsequent node has a random chance of either
inserting each of those elements separately, or to pass on the entire
bundle again to another node. This would give plausible deniability
to the original inserter if the insertion was ever tracked back to
their node.
2. When a node receives a Metadata insert, it should cache it. However,
since
we are limiting comparisons on Metadata to those with the same
cardinality,
we therefore need many MetadataStores, one for each type (cardinality)
of
Metadata. Such MetadataStores could be created on demand. We cache the
Metadata in the appropriate MetadataStore.
3. The node then searches all the items of Metadata in the same
MetadataStore
for the closest one to the inserted Metadata, and forwards the Metadata
to the
DataSource of this entry (with a decreased htl). This closeness
comparison is
completely valid - the cardinalities of the compared MetaData are the
same
(remembering to sort the Metadata elements alphabetically to remove
ambiguity).
Searching Metadata
==================
Because of the insert mechanism, searching is now a doddle. A node
receiving Metadata search criteria of cardinality n looks in the
MetadataStore
of the same cardinality, returns any matches (comprising of the entire
originally inserted metadata), and if needs be, forwards the search to
the
DataSource of the Metadata best matching the search criteria (looked for
in the MetadataStore of the same cardinality of course). It is also
possible
for the node to look in the MetadataStores of cardinalities greater than
the search criteria for matches, but to preserve routing patterns,
these results should not be cached by nodes along the return path.
And thats it.
Advantages
==========
- - Allows fuzzy searching
- - Clustering of Metadata occurs on two separate levels.
1. Nodes may come to specialise in Metadata of a certain
cardinality
2. Clustering occurs within a set of Metadata with a
certain cardinality, due to inserts and requests
being routed along the same path (same effect as key
clustering)
Desired Metadata will therefore be easy to locate.
- - Client software that standardises the type of the search criteria
will lead to many users generating requests of the same cardinality,
leading to even better clustering (such examples include mp3
finders, newsreaders, nym finders etc)
- - Searching is very efficient, because of limiting comparisons
to a subset of all possible Metadata corresonding to a
certain cardinality.
- - There should not be any overloading of nodes due to
popular keyword searches, since only the cardinality of
Metadata is considered, not the datatypes of elements
within Metadata. The 'mp3 effect' will not occur.
Disadvanages
============
- - Searches including excessive criteria may be unlikely to find matches,
since only Metadata of the same cardinality is considered. This can be
countered by client software that suggests refining search criteria
to use less terms, greatly increasing the possibility of matches.
I await your comments
Alex Barnell <aeb99@doc.ic.ac.uk>
- --__--__--
Message: 2
Date: Thu, 08 Jun 2000 12:50:43 +0100
From: Alex Barnell <aeb99@doc.ic.ac.uk>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] Abusing Searches
Reply-To: freenet-chat@lists.sourceforge.net
hal@finney.org wrote:
> There are two problems here. One is accurate keywords which get used
> so much as to be almost useless (like "mp3"), and the other is people
> who intentionally insert their data under incorrect but popular keywords
> (spammers, and Freenet attackers).
>
> The first can be dealt with by indexing using a whole series of keywords.
> You don't just insert under mp3, you insert with mp3 + grateful dead +
> other info, and likewise for the search. (I am still not convinced that
> this fuzzy insert/search concept will work, but it is the best idea I
> have seen so far.)
>
See my recent post which anaylses closeness and suggests a fuzzy
mechanism
that satisfies the requirements of a valid closeness relationship.
> For the second there have been a couple of ideas proposed. One is to
> separate the Freenet "voting" from the fetch. Currently when data is
> fetched it gets propagated and gets its priority boosted. There are a
> couple of proposals allowing people to separate these, so that if the
> data turns out to be bogus, they can "unfetch" it.
>
The problem with unfetching metadata, is that a user may get 100
matches,
and we cannot realistically expect them to check every result, and
unrequest the bogus ones.
> Another idea was to let people "endorse" keyword mappings using
> cryptographic signatures. This would have to be used in the context of a
> PGP style web of trust where each person decides which endorsers to trust.
> Then bogus keywords would not get signed by anyone who was trusted.
>
> I'm not sure this would really scale though, if there could be the right
> number of endorsers: small enough to save all their signatures on each
> metadata file, but large enough that people would have a good chance of
> finding an endorsement they trust on a typical fetch.
A better system is for users to have two continuosly updated files on
Freenet:
(Assuming the user is called nym)
1. users/nym/trusted
2. users/nym/untrusted
These files contain lists of users the user trusts or does not trust.
Intelligent client software can use transitivity of trust to build a
list
of users the user probably trusts. The overhead is not that large,
additionally,
users who are trusted will have their trusted and untrusted lists
progogated
widely over Freenet due to popularity.
- --__--__--
Message: 3
Date: Thu, 08 Jun 2000 13:07:50 +0100
From: Alex Barnell <aeb99@doc.ic.ac.uk>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] metadata makes clients usable
Reply-To: freenet-chat@lists.sourceforge.net
Brandon wrote:
>
> > Brandon,
> > Sorry, there was talk a while back on the developer list about this in
> > general. I don't know where things stand right now. It was my impression
> > searching was making some progress. You picked up on an mistakenly
> > unexcised postscript to my message... any thoughts on metadata?
>
> There is an initial start on searching but no progress is being made as
> far as I know. Also, the start on searching is for keyword searches, not
> substring matches.
I have done a mathematical anaylsis of closeness and metadata searching
It's at http://www.doc.ic.ac.uk/~aeb99/fnsearch.txt. I think the requirements
it places upon potential searching systems are mathematically sound. I have
proposed a system which meets the requirements, although I would imagine there
is a more efficient solution. I am hoping my article will bring some
enlightenment
to the subject!
- --__--__--
Message: 4
Date: Thu, 08 Jun 2000 14:29:39 +0100
From: Ian Clarke <i.clarke@dynamicblue.com>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] A proposal - Hierarchial permissions and chaining
data
Reply-To: freenet-chat@lists.sourceforge.net
> Basically you're suggesting adding support for conditional inserting -
> allowing inserting for specific groups of keys only to entities that sign
> with the appropiate public keys?
Indeed.
> My idea was to simply ignore any directory listing that is not signed by the
> correct public key, and provide read permissions by encrypting the listing,
> so only people who can unencrypt it will know what's in the directory.
But rather than inserting a directory listing pointing to other keys,
you may as well just insert the data for those keys together under one
key. My mechanism permits you to reserve a section of key space to
which you can add keys later, and where people can search for those
keys.
Ian.
- --__--__--
Message: 5
From: "Mikus 29" <mikus_news@hotmail.com>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] Logo Proposal
Date: Thu, 08 Jun 2000 10:24:18 EDT
Reply-To: freenet-chat@lists.sourceforge.net
>From: Jon V <jon@valesh.com>
>
>On Wed, 7 Jun 2000, Rick Dietz wrote:
>
> > > Yep. It is the spikes on the backs, isn't it? Those scary black
>bunnies
> > > yesterday got me thinking, and I *knew* the spikes would be too much,
>but
> > > I couldn't resist trying my hand at a fearsome logo.
> >
> > ...grown men and women, afraid of little black bunnies, that's not the
> > fighting freenet spirit.
>
>...but it makes perfect sense for a bunch of nerds. :)
>
>And, now that I think about it, rabbits really are sort of frightening.
>
>They've got those huge teeth, vicious hind legs, and black, evil eyes.
>They are also carriers of disease, destroyers of crops, and wreckers of
>ecosystems. More human suffering has been borne hareback than any human
>could duplicate. More have died, more spirits have been crushed, more
>fortunes have been lost because of rabbits than because of any general
>ever born. The Australians know the violence that hides behind bunny eyes.
>The Europeans knew it, too.
But, Doesn't that make it an even more ideal mascot?
They look "harmless"...
But, underneath, they are capable of infecting society with a new paradigm,
or world of thought.
Try to stop them, they multiply faster than you can exterminate them.
The destroyers of crops? The destroyers of control? The destroyers of
fortunes (of the power elite)... more metaphors can be thought up, maybe
even a related slogan...
>But they are cute.
>
>:)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
- --__--__--
Message: 6
From: "Mikus 29" <mikus_news@hotmail.com>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] Logo proposal
Date: Thu, 08 Jun 2000 10:30:50 EDT
Reply-To: freenet-chat@lists.sourceforge.net
>From: Andrew Pam <xanni@glasswings.com.au>
>
>On Wed, Jun 07, 2000 at 03:15:34PM -0400, Mikus 29 wrote:
> > > > Or how about "speak freely"
> > >"Share and enjoy"
> > Share Freely... ?
>
>"I. Key Freely"? :)
Now, that's good..... It will definitely stick in the minds of anyone
hearing it. Not a slogan one would forget, at least until they told a few
of their friends...
I'm probably gonna tell a few of my friends, just cuz it's a play on the
other obvious rendition, which IMO is where the idea came from, and serves
well as association...
Mikus
>Cheers,
> *** Xanni ***
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
- --__--__--
Message: 7
From: hal@finney.org
Date: Thu, 8 Jun 2000 08:25:18 -0700
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] Mathematical Reasoning about Searching Freenet
Reply-To: freenet-chat@lists.sourceforge.net
Alex writes:
> 1. For an efficient searching mechanism, Metadata must cluster in some way
> 2. For an arbitary type to cluster, there must be some valid closeness
> relationship defined between any three instances of that type
> 3. For three entities to have a valid closeness relationship between them,
> they must all have the same cardinality (or dimension)
>
> Conclusion: Any efficient searching mechanism must limit any closeness
> comparisons between Metadata to Metadata with the same cardinality.
[Note, your line breaks were messed up making this version hard to read.]
I'm not sure you have justified your point that cardinality differences
will prevent clustering. For clustering to fail, the closeness relation
must be inconsistent. According to Ian's paper, closeness must satisfy
two axioms (I have re-written them slightly to be more clear to me):
If:
B is closer to A than to D
and:
B is closer to E than to A
then:
B is closer to E than to D.
Also, rather trivially:
If:
B equals A
and:
B does not equal D
then:
B is closer to A than to D.
Any closeness relation that satisfies these axioms will allow clustering
and will make Freenet "work".
I'd like to see some specific analysis of why comparisons between metadata
of different dimensionality (or perhaps keyword lists with different
numbers of keywords) will not satisfy these axioms. Perhaps you could
show some examples where it doesn't work.
Only if you can show that the current ideas won't work will it make
sense to look at new ones as you suggest.
Hal
- --__--__--
Message: 8
Date: Thu, 08 Jun 2000 16:35:42 +0100
From: Alex Barnell <aeb99@doc.ic.ac.uk>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] Mathematical Reasoning about Searching Freenet
Reply-To: freenet-chat@lists.sourceforge.net
hal@finney.org wrote:
> I'd like to see some specific analysis of why comparisons between metadata
> of different dimensionality (or perhaps keyword lists with different
> numbers of keywords) will not satisfy these axioms. Perhaps you could
> show some examples where it doesn't work.
>
Here's a (not very good) example:
Node A has some MetaData in it's store, with elements A, B, C and D
Node B wants to forward an inserted Metadata with elements A, B, and E. If we
allow comparisons between arbitary Metadata, then it could forward the insert
to node A, since ABE matched ABCD pretty well.
Noce C wants to forward an inserted Metadata with elements B, C, D, F and G.
Again,
node A looks a good match, since BCDFG matches ABCD to some extent.
Node A now has three pieces of Metadata in it's stores:
1. ABCD
2. ABE
3. BCDFG
We would hope that our mechanism induces clustering. However, is Metadata 2
close
to Metadata 3? Not that close. This is because we have allowed comparisons
between different types of Metadata.
This would never occur in my system.
> Only if you can show that the current ideas won't work will it make
> sense to look at new ones as you suggest.
>
Fair enough, I'm still working on it obviously, I'm hoping that my
ideas can stimulate development.
- --__--__--
Message: 9
From: "Marcel Popescu" <marcel@aiurea.com>
To: <freenet-chat@lists.sourceforge.net>
Subject: Re: [Freenet-chat] Logo Proposal
Date: Thu, 8 Jun 2000 10:39:11 -0500
Reply-To: freenet-chat@lists.sourceforge.net
From: "Jon V" <jon@valesh.com>
> And there is a truth behind all of those reasons: A society that is unable
> to police its members, unable to enforce its laws, cannot survive.
Oops... everything was beautiful so far; if you replace "society" with
"government", then the above phrase will fit nicely.
Mark
- --__--__--
Message: 10
Date: Thu, 08 Jun 2000 11:53:43 -0400
From: "Stover, Michael" <Michael.Stover@usa.xerox.com>
Subject: RE: [Freenet-chat] Napster orders Offspring to stop pirating the
Napster logo
To: "'freenet-chat@lists.sourceforge.net'" <freenet-chat@lists.sourceforge.net>
Reply-To: freenet-chat@lists.sourceforge.net
Marcel Popescu writes:
> I don't agree that rights are conditioned by what people think about them.
I
> am from the "natural rights" school (of course, as a Christian, I believe
> that rights were granted by God, but that's not very important for this
> matter), and therefore I consider that people simply have rights, because
> they are humans, and work from that up.
Apparently, your Christian beliefs are very important to this discussion,
because they are leading you to believe that people "simply have rights,
because they are humans". Your particularly feelings about your rights are
not verifiable, however. There aren't any "natural rights" that can be
verified beyond the right to do whatever you can get away with, and that's
just not very useful to us.
It seems any discussion about rights, morals, and ethics always gets bogged
down in the same old cruft - believing there's an actual set of rules that
we have to "discover" that will answer the questions for all time.
But, I think there's an easier way to approach the problem. Rights and
morals are concepts that get at trying to solve a problem - namely, how do
we want to live, and what's the best way to make that happen? For example,
if I want to be able to walk around freely without fearing someone will kill
me, one way to do that is make murder against the law, lock up anyone who
does it (as a deterrent), and furthermore, instill in people a moral
imperative against killing. That last part achieves the goal with a pretty
high degree of success. However, to say there is a God who did this, who
set up this rule, takes away from the real work that was actually done, by
humans, to accomplish this feat. In fact, we did it to ourselves, for the
purpose of improving our existence.
This way of looking at things gives us a powerful tool to use in trying to
solve other problems. If you define the problem you're trying to solve
accurately, then you should be able to develop a good solution to it. That
solution may involve enacting laws (enforced by police), or modifying
cultural norms, or technological measures. But a discussion of natural or
inalienable rights only succeeds in obscuring the issues.
To comment on another thread briefly, if censorship is a problem that
freenet is trying to solve, then a good definition of the problem is indeed
required, and it should be noted that freenet is a technological solution to
that problem. This has important ramifications if copywrite is defined as a
method of censorship, because then freenet is pitting itself squarely
against the government.
Further, it is useless to argue whether copywrite laws are moral, immoral,
right, or wrong. They serve a purpose - they are an attempt to solve a
problem (whether that problem is well-defined or actually exists is another
matter). If we move our arguments onto this more concrete basis, I think
we'll be more productive.
- -Mike Stover
- --__--__--
Message: 11
From: Pierre Abbat <phma@oltronics.net>
To: freenet-chat@lists.sourceforge.net
Subject: Re: [Freenet-chat] Mathematical Reasoning about Searching Freenet
Date: Thu, 8 Jun 2000 11:24:13 -0400
Reply-To: freenet-chat@lists.sourceforge.net
>Metadata A:
> Title = Graphic Java
> Author = David Geary
> Publisher = The Sunsoft Press
>
> |A| = 3
>
>Metadata B:
> Content-type = audio/mp3
> Artist = Metallica
> Song = We will fuck with you, evil Freenet developers
> Year = 2000
> Bitrate = 128KBps
>
> |B| = 5
>
>Metadata C:
> Picture = Hopstolive the Rabbit
> Author = Oskar
>
> |C| = 2
A is closer to C than to B, because A and C both have authors, and they have
the sequence of letters (a,r) in common, whereas A and B have no fields in
common.
I think closeness should be defined as follows:
Take the set of metadata fields D and E have in common.
For each field, find the length of the longest common subsequence of characters.
Total these numbers. The larger the total, the closer D and E are.
Another example:
A:
Author = Joan Daemen
Title = Crypto
B:
Author = Bruce Schneier
Title = The Blowfish Encryption Algorithm
Publisher = Counterpane
C:
Author = Joan Baez
Title = Gone from Danger
Content-type = audio/mp3
The closeness of A to B is computed as follows:
Author: "nee"
Title: "rypto"
Total: 8
A to C is:
Author: "Joan ae"
Title: "ro"
Total: 9
So A is closer to C than to B.
phma
- --__--__--
_______________________________________________
Freenet-chat mailing list
Freenet-chat@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-chat
End of Freenet-chat Digest
------- End of Forwarded Message