On 5/19/06, Matthew Toseland wrote:
> I propose:
> - We implement a Simple Revocable Key wrapper. This is simply a USK,
> with the prefix being SRK instead of USK, and where we check for
> SSK@/revoked. If this exists we return a permanent redirect to
> it, instead of the data to be
HUS - Nothing is impossible. Our Boss says so.
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- 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/devl/attachments/20060519/d26d363a/attachment.pgp>
-
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/devl/attachments/20060519/586eeea0/attachment.pgp>
--
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/devl/attachments/20060519/a26904f8/attachment.pgp>
On 5/19/06, Ian Clarke wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I think this is much more complicated than we need, at least for an
> initial implementation of RSKs.
>
> All we really need is to standardize on a "revoked" key within an SSK
> that will be checked before Freenet
__
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/ae18e621/attachment.pgp>
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/9b80e741/attachment.pgp>
demonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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.
-- 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/devl/attachments/20060519/f9af136e/attachment.pgp>
Per Ian's request, I have temporarily taken down Ubernode.org-
As I said in my first e-mail, I think a website that exchanged references
is a better design, and if someone is interested in making that, I'm happy
not to run an ubernode.
That said, I still think it would be an interesting test, and
TURE-
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/762b2879/attachment.pgp>
ed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060519/949b5d42/attachment.pgp>
Ian Clarke wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 19 May 2006, at 10:17, Matthew Toseland wrote:
>
>> On Fri, May 19, 2006 at 10:10:03AM -0700, Ian Clarke wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Note that compressing anything that has
__
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says s
. Our Boss says so.
-- 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/devl/attachments/20060519/57f7b01c/attachment.pgp>
t; Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/60a27d36/attachment.pgp>
//freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/34dad9a9/attachment.pgp>
ypes td {
> font-size: 7pt;
> }
> +
> +/* queue page */
> +
> +table.queue th, table.queue td {
> + font-size: 8pt;
> +}
> +
> +div.queue_tabletitle {
> + margin: 0;
> + padding: 10px 0 10px 0;
> + font-size: 10pt;
> +}
> +
> +table.queue span {
> + font-size: 8pt;
> +}
> +
> +table.queue span.failure_reason_unknown {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.failure_reason_is {
> +}
> +
> +table.queue span.progress_fraction_unknown {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.progress_fraction_not_finalized {
> +}
> +
> +table.queue span.progress_fraction_finalized {
> + color: #008000;
> +}
> +
> +table.queue span.number_of_files {
> +}
> +
> +table.queue span.number_of_files {
> +}
> +
> +table.queue span.filename_direct {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.filename_none {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.filename_is {
> +}
> +
> +table.queue span.identifier_with_uri {
> +}
> +
> +table.queue span.persistence_none {
> +}
> +
> +table.queue span.persistence_reboot {
> + color: #ff;
> +}
> +
> +table.queue span.persistence_forever {
> + color: #00b000;
> +}
> +
> +table.queue span.mimetype_unknown {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.mimetype_is {
> +}
> +
> +table.queue span.filesize_unknown {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.filesize_is {
> +}
> +
> +table.queue span.key_unknown {
> + color: #d0d0d0;
> +}
> +
> +table.queue span.key_is {
> +}
>
> Modified: trunk/freenet/src/freenet/support/SizeUtil.java
> ===
> --- trunk/freenet/src/freenet/support/SizeUtil.java 2006-05-19 13:40:22 UTC
> (rev 8786)
> +++ trunk/freenet/src/freenet/support/SizeUtil.java 2006-05-19 14:37:22 UTC
> (rev 8787)
> @@ -8,10 +8,10 @@
> public static String formatSize(long sz) {
> // First determine suffix
>
> - String suffixes = "kMGTPEZY";
> + String[] suffixes = {"B",
> "KiB","MiB","GiB","TiB","PiB","EiB","ZiB","YiB"};
> long s = 1;
> int i;
> - for(i=0;i<suffixes.length();i++) {
> + for(i=0;i<suffixes.length;i++) {
> s *= 1000;
> if(s > sz) {
> break;
> @@ -20,15 +20,20 @@
> }
>
> s /= 1000; // we use the previous unit
> - double mantissa = (double)sz / (double)s;
> - String o = Double.toString(mantissa);
> - if(o.indexOf('.') == 3)
> - o = o.substring(0, 3);
> - else if(o.indexOf('.') > -1 && o.indexOf('E') == -1 &&
> o.length() > 4)
> - o = o.substring(0, 4);
> - if(i > 0) o += suffixes.charAt(i-1);
> - o += "B";
> - return o;
> + if (s == 1) // Bytes?
> + {
> + return sz + " " + suffixes[0];
> + }
> + else
> + {
> + double mantissa = (double)sz / (double)s;
> + String o = Double.toString(mantissa);
> + if(o.indexOf('.') == 3)
> + o = o.substring(0, 3);
> + else if(o.indexOf('.') > -1 && o.indexOf('E') == -1 &&
> o.length() > 4)
> + o = o.substring(0, 4);
> + o += " " + suffixes[i];
> + return o;
> + }
> }
> -
> }
>
> ___
> cvs mailing list
> cvs at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs
>
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
- End forwarded message -
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/a944c8b5/attachment.pgp>
>> (By the way there's a paper in this year's PET workshop about hiding the
>> source of Chord lookups using fuzzy routing, which sounds like it might
>> be relevant to greedy routing in Freenet.)
>
> Interesting.
Looks like this might be the tech report:
ilman/listinfo/devl
>
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/6a8a142d/attachment.pgp>
J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
D
nt was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060519/2dcfa463/attachment.pgp>
___
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> >
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-- 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/devl/attachments/20060519/e1c07847/attachment.pgp>
.
-- 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/devl/attachments/20060519/bd8801b4/attachment.pgp>
..
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060519/8c17d96f/attachment.pgp>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sounds good.
Ian.
On 19 May 2006, at 12:54, Matthew Toseland wrote:
> I propose:
> - We implement a Simple Revocable Key wrapper. This is simply a USK,
> with the prefix being SRK instead of USK, and where we check for
> SSK@/revoked. If this
Matthew Toseland wrote:
> On Fri, May 19, 2006 at 01:45:26PM -0500, David Sowder (Zothar) wrote:
>
>> It seems to me that a node could benefit from knowing that it doesn't
>> need to do outgoing hole punching.
>>
>> Some possible benefits:
>>
>> - The node wouldn't need to send handshakes to
>> High level question: Why is it necessary to support several =20
>> compression standards?
>
>I'm not sure either that it is a good idea.
>
>NextGen$
I think we should only support ONE compression scheme. It should be fairly
STANDARD, read: _100%_ of other languages (c, cpp, cs, php, perl,
It seems to me that a node could benefit from knowing that it doesn't
need to do outgoing hole punching.
Some possible benefits:
- The node wouldn't need to send handshakes to disconnected nodes nearly
as often for nodes we haven't heard from in some time period
- The node wouldn't need to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think this is much more complicated than we need, at least for an
initial implementation of RSKs.
All we really need is to standardize on a "revoked" key within an SSK
that will be checked before Freenet returns the contents of the SSK,
an
Why don't you just wait for the open net?
Dark net is supposed to be dark, so the Slashdot crowd should use the open
net. Dark net is only an advantage if you have low availability. If it is
legal where you are connecting from you should always use the open net.
But it is an interesting test non
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 May 2006, at 10:17, Matthew Toseland wrote:
> On Fri, May 19, 2006 at 10:10:03AM -0700, Ian Clarke wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Note that compressing anything that has already been compressed, such
>> as most
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that compressing anything that has already been compressed, such
as most image, audio, or video formats, is pointless.
Ian.
On 19 May 2006, at 09:56, Matthew Toseland wrote:
> Most of the time I expect the node to decide what goes into a
>
So, bzip2...
On 5/19/06, freenetwork at web.de wrote:
> >> High level question: Why is it necessary to support several =20
> >> compression standards?
> >
> >I'm not sure either that it is a good idea.
> >
> >NextGen$
>
> I think we should only support ONE compression scheme. It should be
For the purposes of testing, and regarding the thoughts in my last e-
mail, I've set up two freenet nodes which are public- Anyone can add
their reference to them, without interaction by me.
Note- This is entirely different from the link exchange idea that I
proposed in my last e-mail. I
Freenet .7 is designed to work through a series of connections
between individuals- When a person first joins the Freenet darknet,
they are expected to join with at least three people they know and
trust.
While this may be attainable once there are a high number of network
users, With
* Ian Clarke [2006-05-18 13:11:34]:
> High level question: Why is it necessary to support several
> compression standards?
I'm not sure either that it is a good idea.
NextGen$
> Wouldn't it be simpler just to support one
> (ie. the one that achieves the best compression, without
High level question: Why is it necessary to support several =20
compression standards?
I'm not sure either that it is a good idea.
NextGen$
I think we should only support ONE compression scheme. It should be fairly
STANDARD, read: _100%_ of other languages (c, cpp, cs, php, perl, lisp,
So, bzip2...
On 5/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
High level question: Why is it necessary to support several =20
compression standards?
I'm not sure either that it is a good idea.
NextGen$
I think we should only support ONE compression scheme. It should be fairly
On Thu, May 18, 2006 at 01:11:34PM -0700, Ian Clarke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
High level question: Why is it necessary to support several
compression standards? Wouldn't it be simpler just to support one
(ie. the one that achieves the best compression,
On Thu, May 18, 2006 at 07:59:03PM +0100, Michael Rogers wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Toseland wrote:
- Any other ideas?
I was going to suggest slowly spinning the network: each node increments
its location by a tiny amount each day (mod 1), so each key
On Thu, May 18, 2006 at 11:05:38PM +0200, Florent Daigni?re (NextGen$) wrote:
* Ian Clarke [EMAIL PROTECTED] [2006-05-18 13:11:34]:
High level question: Why is it necessary to support several
compression standards?
I'm not sure either that it is a good idea.
It is vital to support
On Fri, May 19, 2006 at 09:55:04AM -0300, Caco Patane wrote:
So, bzip2...
bzip2 is slow (to compress). Gzip is fastest, but 7zip appears to me
(entirely subjectively) to be faster than bzip2.
On 5/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
High level question: Why is it necessary to
(By the way there's a paper in this year's PET workshop about hiding the
source of Chord lookups using fuzzy routing, which sounds like it might
be relevant to greedy routing in Freenet.)
Interesting.
Looks like this might be the tech report:
- Forwarded message from Mail Delivery System [EMAIL PROTECTED] -
From: Mail Delivery System [EMAIL PROTECTED]
Subject: Undelivered Mail Returned to Sender
To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on servalan
X-Spam-Level:
X-Spam-Status: No, score=0.0
On Fri, May 19, 2006 at 05:05:11PM +0100, Michael Rogers wrote:
(By the way there's a paper in this year's PET workshop about hiding the
source of Chord lookups using fuzzy routing, which sounds like it might
be relevant to greedy routing in Freenet.)
Interesting.
Looks like this might be
Why don't you just wait for the open net?
Dark net is supposed to be dark, so the Slashdot crowd should use the open
net. Dark net is only an advantage if you have low availability. If it is
legal where you are connecting from you should always use the open net.
But it is an interesting test non
On Fri, May 19, 2006 at 10:39:18AM +0200, Lean Fuglsang wrote:
Why don't you just wait for the open net?
Dark net is supposed to be dark, so the Slashdot crowd should use the open
net. Dark net is only an advantage if you have low availability. If it is
legal where you are connecting from you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that compressing anything that has already been compressed, such
as most image, audio, or video formats, is pointless.
Ian.
On 19 May 2006, at 09:56, Matthew Toseland wrote:
Most of the time I expect the node to decide what goes into a
On Fri, May 19, 2006 at 10:10:03AM -0700, Ian Clarke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that compressing anything that has already been compressed, such
as most image, audio, or video formats, is pointless.
True, but packing them may be far from pointless. Also,
Ian Clarke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 May 2006, at 10:17, Matthew Toseland wrote:
On Fri, May 19, 2006 at 10:10:03AM -0700, Ian Clarke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that compressing anything that has already been compressed, such
RSKs will be implemented soon. Details:
A SIMPLE_REVOCABLE metadata document contains:
- A target URI.
- A list of Trustee's
- int: Minimum # biased votes to block the site
- int: Minimum # votes to block the site
- int: Minimum # biased votes to modify the RSK
- int: Minimum # votes to modify
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think this is much more complicated than we need, at least for an
initial implementation of RSKs.
All we really need is to standardize on a revoked key within an SSK
that will be checked before Freenet returns the contents of the SSK,
an
On Fri, May 19, 2006 at 11:26:10AM -0700, Ian Clarke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think this is much more complicated than we need, at least for an
initial implementation of RSKs.
All we really need is to standardize on a revoked key within an SSK
that will
On 5/19/06, Ian Clarke [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think this is much more complicated than we need, at least for an
initial implementation of RSKs.
All we really need is to standardize on a revoked key within an SSK
that will be checked before
It seems to me that a node could benefit from knowing that it doesn't
need to do outgoing hole punching.
Some possible benefits:
- The node wouldn't need to send handshakes to disconnected nodes nearly
as often for nodes we haven't heard from in some time period
- The node wouldn't need to do
On Fri, May 19, 2006 at 08:38:35PM +0200, Lars Juel Nielsen wrote:
I like the initial post but as Ian say it is overkill at least for
now. The problem is, how hard will it be to update it later to a
better solution if needed?
As far as I can see Matthew's proposal cover any possible case,
On Fri, May 19, 2006 at 01:45:26PM -0500, David Sowder (Zothar) wrote:
It seems to me that a node could benefit from knowing that it doesn't
need to do outgoing hole punching.
Some possible benefits:
- The node wouldn't need to send handshakes to disconnected nodes nearly
as often for
Why?
On Fri, May 19, 2006 at 09:11:57PM +0200, Florent Daigni?re (NextGen$) wrote:
* Matthew Toseland [EMAIL PROTECTED] [2006-05-19 20:04:14]:
On Fri, May 19, 2006 at 08:38:35PM +0200, Lars Juel Nielsen wrote:
I like the initial post but as Ian say it is overkill at least for
now.
* Matthew Toseland [EMAIL PROTECTED] [2006-05-19 20:13:02]:
Why?
1) new keytypes don't hurt
2) I'm still not convinced by the trustees system : The security of RSKs
resides in the ability for the 'client' to fetch a revocation
certificate.
The revocation has to be done BEFORE a client tries to
On Fri, May 19, 2006 at 09:21:35PM +0200, Florent Daigni?re (NextGen$) wrote:
* Matthew Toseland [EMAIL PROTECTED] [2006-05-19 20:13:02]:
Why?
1) new keytypes don't hurt
2) I'm still not convinced by the trustees system : The security of RSKs
resides in the ability for the 'client' to
Matthew Toseland wrote:
On Fri, May 19, 2006 at 01:45:26PM -0500, David Sowder (Zothar) wrote:
It seems to me that a node could benefit from knowing that it doesn't
need to do outgoing hole punching.
Some possible benefits:
- The node wouldn't need to send handshakes to disconnected nodes
I propose:
- We implement a Simple Revocable Key wrapper. This is simply a USK,
with the prefix being SRK instead of USK, and where we check for
SSK@pubkey/revoked. If this exists we return a permanent redirect to
it, instead of the data to be returned otherwise.
This does not affect
On 5/19/06, Matthew Toseland [EMAIL PROTECTED] wrote:
I propose:
- We implement a Simple Revocable Key wrapper. This is simply a USK,
with the prefix being SRK instead of USK, and where we check for
SSK@pubkey/revoked. If this exists we return a permanent redirect to
it, instead of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sounds good.
Ian.
On 19 May 2006, at 12:54, Matthew Toseland wrote:
I propose:
- We implement a Simple Revocable Key wrapper. This is simply a USK,
with the prefix being SRK instead of USK, and where we check for
SSK@pubkey/revoked. If this
Matthew Toseland wrote:
I propose:
- We implement a Simple Revocable Key wrapper. This is simply a USK,
with the prefix being SRK instead of USK, and where we check for
SSK@pubkey/revoked. If this exists we return a permanent redirect to
it, instead of the data to be returned otherwise.
On Friday 19 May 2006 18:56, Matthew Toseland wrote:
Most of the time I expect the node to decide what goes into a
container. How can it decide this? I propose the following rules:
By all means, include something that lets the user decide about the
packaging.
Maybe on ClientPutComplexDir,
Yes, it's purely an advisory. It's designed to deal with key compromize.
It's explicitly not a deletion mechanism.
On Sat, May 20, 2006 at 12:10:22PM +1200, David McNab wrote:
Matthew Toseland wrote:
I propose:
- We implement a Simple Revocable Key wrapper. This is simply a USK,
with the
Ian Clarke - [EMAIL PROTECTED] wrote:
On 19 May 2006, at 10:17, Matthew Toseland wrote:
On Fri, May 19, 2006 at 10:10:03AM -0700, Ian Clarke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Note that compressing anything that has already been compressed, such
as most image, audio, or
69 matches
Mail list logo
