Re: [freenet-dev] Infocalypse WoT Usage

2013-08-02 Thread Steve Dougherty
On 08/02/2013 08:22 AM, Matthew Toseland wrote:
> On Friday 02 Aug 2013 02:00:59 xor wrote:
> [snip]
 In that case, I should probably implement 
 "GetIdentitiesByPartialNickname".
>>> 
>>> That would be very useful not only for this project but also for 
>>> anything that wants to have autocomplete. (Such as Freemail
>>> recipients in the "to" field of the web interface.)
>> 
>> Fine. Then I get your point now. Now the question is: When should I
>> implement it?
>> 
>> The next point on my roadmap is getting event-notifications in a
>> merge-able state. This probably will take a full month. I had
>> already delayed event-notifications for a month due to other work. 
>> Implementing GetIdentitiesByPartialNickname take a full week or
>> even two. It would have to be done in a proper way to be persistent
>> and use the database.
>> 
>> How easy is it for you to work without this feature right now? Can
>> you use a dummy-implementation until I finish event-notifications?
>> 
>> Event-notifications would also be useful for you maybe to deliver
>> pull-requests by solving a captcha of the person who shall receive
>> the pull request.
>> 
>> Toad, what do you think?
>> 
> I'd bounce this back to operhiem1. Does p0s working on this in the
> relatively near future save you a lot of work? If not, it should be
> postponed until after event notifications.

I see no need to prioritize working on this in the near future.
WoT-integrated Infocalypse features still work without
GetIdentitiesByPartialNickname. It falls back to GetIdentity, which
means for non-local identities the entire identity ID must be specified.
This removes the convenience of partial matching, but it does still
function.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-08-02 Thread Matthew Toseland
On Friday 02 Aug 2013 02:00:59 xor wrote:
> (Reply split in two mails since I need the answer of toad for only one of 
> them - for this one)
> 
> On Tuesday, July 30, 2013 07:01:05 PM Steve Dougherty wrote:
> > > How do you obtain the list of identities which you offer the user to chose
> > > from? You should use GetIdentitiesByScore with positive score filter (and
> > > context filter "Infocalypse", I think it supports that as well). Where do
> > > you present him with the list? Ideally, the UI which shows the list
> > > should pass through the ID so you don't have to filter by nickname.
> > 
> > There is no list to choose from. The user types something like "hg pull
> > freenet:p0s/WoT" and Infocalypse resolves it to a URI (not necessarily
> > one in the same subspace) and fetches it.
> > 
> > > But I guess you might be using command line only so the user needs to be
> > > free to pass nicknames without ID?
> > 
> > Yes.
> > 
> > > In that case, I should probably implement
> > > "GetIdentitiesByPartialNickname".
> > 
> > That would be very useful not only for this project but also for
> > anything that wants to have autocomplete. (Such as Freemail recipients
> > in the "to" field of the web interface.)
> 
> Fine. Then I get your point now.
> Now the question is: When should I implement it?
> 
> The next point on my roadmap is getting event-notifications in a merge-able 
> state. This probably will take a full month.
> I had already delayed event-notifications for a month due to other work.
> Implementing GetIdentitiesByPartialNickname take a full week or even two. It 
> would have to be done in a proper way to be persistent and use the database.
> 
> How easy is it for you to work without this feature right now?
> Can you use a dummy-implementation until I finish event-notifications?
> 
> Event-notifications would also be useful for you maybe to deliver 
> pull-requests 
> by solving a captcha of the person who shall receive the pull request.
> 
> Toad, what do you think?
> 
I'd bounce this back to operhiem1. Does p0s working on this in the relatively 
near future save you a lot of work? If not, it should be postponed until after 
event notifications.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Infocalypse WoT Usage

2013-08-02 Thread xor
(Reply split in two mails since I need the answer of toad for only one of 
them - for this one)

On Tuesday, July 30, 2013 07:01:05 PM Steve Dougherty wrote:
> > How do you obtain the list of identities which you offer the user to chose
> > from? You should use GetIdentitiesByScore with positive score filter (and
> > context filter "Infocalypse", I think it supports that as well). Where do
> > you present him with the list? Ideally, the UI which shows the list
> > should pass through the ID so you don't have to filter by nickname.
> 
> There is no list to choose from. The user types something like "hg pull
> freenet:p0s/WoT" and Infocalypse resolves it to a URI (not necessarily
> one in the same subspace) and fetches it.
> 
> > But I guess you might be using command line only so the user needs to be
> > free to pass nicknames without ID?
> 
> Yes.
> 
> > In that case, I should probably implement
> > "GetIdentitiesByPartialNickname".
> 
> That would be very useful not only for this project but also for
> anything that wants to have autocomplete. (Such as Freemail recipients
> in the "to" field of the web interface.)

Fine. Then I get your point now.
Now the question is: When should I implement it?

The next point on my roadmap is getting event-notifications in a merge-able 
state. This probably will take a full month.
I had already delayed event-notifications for a month due to other work.
Implementing GetIdentitiesByPartialNickname take a full week or even two. It 
would have to be done in a proper way to be persistent and use the database.

How easy is it for you to work without this feature right now?
Can you use a dummy-implementation until I finish event-notifications?

Event-notifications would also be useful for you maybe to deliver pull-requests 
by solving a captcha of the person who shall receive the pull request.

Toad, what do you think?


[freenet-dev] Infocalypse WoT Usage

2013-08-02 Thread xor
(Reply split in two mails since I need the answer of toad for only one of 
them)

On Tuesday, July 30, 2013 07:01:05 PM Steve Dougherty wrote:
> On 07/30/2013 05:45 PM, xor wrote:
> > On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote:
> >> At p0s' request here's some information about how Infocalypse currently
> >> uses WoT.
> >> 
> >> Infocalypse sets a "vcs" context on identities when they create a
> >> repository, and inserts a list of repositories under the identity's
> >> subspace at /vcs/.
> > 
> > "VCS" as in "Version control system" is a general term and hg/Infocalypse
> > for sure is not the only one.
> 
> This is the intent. OThere are fields to specify what VCS is being used
> in both pull requests and the repository lists. One of the initial
> design goals was to allow other source control systems to add support
> for Freenet in the same way. I hope for the Infocalypse web UI Fred
> plugin to be VCS agnostic so that it could be used with anything that
> communicates with it properly over FCP. I guess that makes the name wrong.

Generic code is usually a very good design so I appreciate this effort.
However it is notable that the nature of open source development might still 
lead to multiple implementations of generic VCS systems.
We already have an example of this with FMS and Freetalk both implementing the 
same service but being separate spaces due to incompatible design decisions.

So I still vote for this:
> > I think you should use "Infocalypse" as context name and as part of the
> > URI. This would be coherent with "Freetalk" as Freetalk context name and
> > URI subspace and "WebOfTrust" as WOT subspace.


Re: [freenet-dev] Infocalypse WoT Usage

2013-08-01 Thread Steve Dougherty
On 08/01/2013 06:56 AM, Matthew Toseland wrote:
> On Wednesday 31 Jul 2013 17:00:50 Arne Babenhauserheide wrote:
>> Am Mittwoch, 31. Juli 2013, 15:50:17 schrieb Matthew Toseland:
>>> Okay. The difficulty here is that there might be more than one
>>> p0s. We should always use the p0s we used last time, for
>>> security's sake. This is probably part of the reason why e.g. git
>>> has a list of remotes for each repository.
>> 
>> You can set explicit paths per repository ([paths] heading in
>> REPO/.hg/hgrc). and IIRC clone does this using the identities USK.
>> So when you clone a repository, the default pull path will always
>> lead to the same repository.
> 
> Right, but what about pulling from a repository other than the
> origin/default? I may regularly review and merge code from a handful
> of other repositories and push it into "my" repository. I need to
> know when I do "git pull operhiem1", or the equivalent hg command, it
> pulls from the same repo as last time.

All of us are proposing things that lead to performing resolution only
once, after which a URI is saved under a constant name. If my
understanding is correct, Mercurial's paths have no equivalent to "git
remote add" - people are intended to edit a configuration file.

How about this: pulling from a WoT repository sets a path with the
resolved URI so the user can use it in the future to refer to the same
identity / repository. It could also be useful to have "hg fn-wot-path".

$ hg fn-wot-path operhiem1/pyProbe # Possible without --wot or similar?
Fetching
USK@pxtehdTmfJwyNUAW2Clk4pwv7Nshyg21NNfXcqzFv4,LTjcTWqvsq3ju6pMGe9Cqb3scvQgECG81hRdgj5WO4s,AQACAAE/vcs/0
Parsing.
Found repository "pyProbe" at
USK@pxtehdTmfJwyNUAW2Clk4pwv7Nshyg21NNfXcqzFv4,LTjcTWqvsq3ju6pMGe9Cqb3scvQgECG81hRdgj5WO4s,AQACAAE/pyProbe.R1/10
Added as path "operhiem1".
$ hg pull operhiem1
Request URI:
USK@pxtehdTmfJwyNUAW2Clk4pwv7Nshyg21NNfXcqzFv4,LTjcTWqvsq3ju6pMGe9Cqb3scvQgECG81hRdgj5WO4s,AQACAAE/pyProbe.R1/10
...

The path's edition would have to be kept up to date, but that's not the
core problem.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-08-01 Thread Matthew Toseland
On Thursday 01 Aug 2013 12:14:48 Matthew Toseland wrote:
> On Thursday 01 Aug 2013 12:04:17 Matthew Toseland wrote:
> > On Wednesday 31 Jul 2013 23:27:26 Steve Dougherty wrote:
> > > On 07/31/2013 10:50 AM, Matthew Toseland wrote:
> > > > On Wednesday 31 Jul 2013 00:01:05 Steve Dougherty wrote:
> > > >> On 07/30/2013 05:45 PM, xor wrote:
> > > >>> On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote: 
> > > >>> [snip]
> > > >>> How do you obtain the list of identities which you offer
> > > >>> the user to chose from? You should use GetIdentitiesByScore with
> > > >>> positive score filter (and context filter "Infocalypse", I think
> > > >>> it supports that as well). Where do you present him with the
> > > >>> list? Ideally, the UI which shows the list should pass through
> > > >>> the ID so you don't have to filter by nickname.
> > > >> 
> > > >> There is no list to choose from. The user types something like "hg
> > > >> pull freenet:p0s/WoT" and Infocalypse resolves it to a URI (not
> > > >> necessarily one in the same subspace) and fetches it.
> > > > 
> > > > Okay. The difficulty here is that there might be more than one p0s.
> > > > We should always use the p0s we used last time, for security's sake.
> > > > This is probably part of the reason why e.g. git has a list of
> > > > remotes for each repository.
> > > > 
> > > > Maybe you should keep a list of aliases? Or boost an identity's trust
> > > > when you pull from it? Really this should be WoT functionality.
> > > 
> > > I don't see why this needs to be anything more complex than aborting
> > > when an identifier used to look up an identity matches more than one
> > > identity. One need only specify the entire identity ID, perhaps with
> > > nickname for convenience, to always uniquely specify an identity. This
> > > partial matching is only for convenience.
> > 
> > That makes a DoS too easy, makes mistakes too easy, and generally sucks 
> > lemons for both security and usability.
> > > 
> > > For local identities it should be really easy for someone to figure out
> > > which one they mean because the search space is very limited, and they
> > > created every identity in it. For remote identities it might involve
> > > more investigation.
> > > 
> > > I think that making sure the identifier refers to the identity they want
> > > is the user's responsibility, not the software's responsibility. All the
> > > software has to do is halt if the user is anything less than specific
> > > enough to be exact.
> > 
> > Git already HAS this functionality. A git repository has a list of remotes 
> > by nickname. Each remote corresponds to a specific external repository URL. 
> > That's all I'm asking for.
> > > 
> > > The only possible problem I see with this is people pasting nicknames
> > > with maliciously indistinguishable UTF-8 characters intended to
> > > impersonate another identity. The solution to that is: "Type the
> > > nickname yourself or check/include the identity ID."
> > 
> > More dubious security issues for no reason. :(
> > 
> > git remote add operhiem1 operhiem1/fred
> >  Look it up at *this* point
> 
> Sorry, to clarify, the last part is a (git) url:
> git remote add operhiem1 freenet:operhiem1/fred
> 
> > git pull operhiem1
> >  Use the full URL (public key / USK / WoT identity) that we added.
> 
Then there is the broader question of whether we want a *global* persistent 
mapping from nick to USK. Which would certainly be useful for e.g. Freemail. 
That's the wider discussion.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-08-01 Thread Matthew Toseland
On Thursday 01 Aug 2013 12:04:17 Matthew Toseland wrote:
> On Wednesday 31 Jul 2013 23:27:26 Steve Dougherty wrote:
> > On 07/31/2013 10:50 AM, Matthew Toseland wrote:
> > > On Wednesday 31 Jul 2013 00:01:05 Steve Dougherty wrote:
> > >> On 07/30/2013 05:45 PM, xor wrote:
> > >>> On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote: 
> > >>> [snip]
> > >>> How do you obtain the list of identities which you offer
> > >>> the user to chose from? You should use GetIdentitiesByScore with
> > >>> positive score filter (and context filter "Infocalypse", I think
> > >>> it supports that as well). Where do you present him with the
> > >>> list? Ideally, the UI which shows the list should pass through
> > >>> the ID so you don't have to filter by nickname.
> > >> 
> > >> There is no list to choose from. The user types something like "hg
> > >> pull freenet:p0s/WoT" and Infocalypse resolves it to a URI (not
> > >> necessarily one in the same subspace) and fetches it.
> > > 
> > > Okay. The difficulty here is that there might be more than one p0s.
> > > We should always use the p0s we used last time, for security's sake.
> > > This is probably part of the reason why e.g. git has a list of
> > > remotes for each repository.
> > > 
> > > Maybe you should keep a list of aliases? Or boost an identity's trust
> > > when you pull from it? Really this should be WoT functionality.
> > 
> > I don't see why this needs to be anything more complex than aborting
> > when an identifier used to look up an identity matches more than one
> > identity. One need only specify the entire identity ID, perhaps with
> > nickname for convenience, to always uniquely specify an identity. This
> > partial matching is only for convenience.
> 
> That makes a DoS too easy, makes mistakes too easy, and generally sucks 
> lemons for both security and usability.
> > 
> > For local identities it should be really easy for someone to figure out
> > which one they mean because the search space is very limited, and they
> > created every identity in it. For remote identities it might involve
> > more investigation.
> > 
> > I think that making sure the identifier refers to the identity they want
> > is the user's responsibility, not the software's responsibility. All the
> > software has to do is halt if the user is anything less than specific
> > enough to be exact.
> 
> Git already HAS this functionality. A git repository has a list of remotes by 
> nickname. Each remote corresponds to a specific external repository URL. 
> That's all I'm asking for.
> > 
> > The only possible problem I see with this is people pasting nicknames
> > with maliciously indistinguishable UTF-8 characters intended to
> > impersonate another identity. The solution to that is: "Type the
> > nickname yourself or check/include the identity ID."
> 
> More dubious security issues for no reason. :(
> 
> git remote add operhiem1 operhiem1/fred
>  Look it up at *this* point

Sorry, to clarify, the last part is a (git) url:
git remote add operhiem1 freenet:operhiem1/fred

> git pull operhiem1
>  Use the full URL (public key / USK / WoT identity) that we added.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-08-01 Thread Matthew Toseland
On Wednesday 31 Jul 2013 23:27:26 Steve Dougherty wrote:
> On 07/31/2013 10:50 AM, Matthew Toseland wrote:
> > On Wednesday 31 Jul 2013 00:01:05 Steve Dougherty wrote:
> >> On 07/30/2013 05:45 PM, xor wrote:
> >>> On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote: 
> >>> [snip]
> >>> How do you obtain the list of identities which you offer
> >>> the user to chose from? You should use GetIdentitiesByScore with
> >>> positive score filter (and context filter "Infocalypse", I think
> >>> it supports that as well). Where do you present him with the
> >>> list? Ideally, the UI which shows the list should pass through
> >>> the ID so you don't have to filter by nickname.
> >> 
> >> There is no list to choose from. The user types something like "hg
> >> pull freenet:p0s/WoT" and Infocalypse resolves it to a URI (not
> >> necessarily one in the same subspace) and fetches it.
> > 
> > Okay. The difficulty here is that there might be more than one p0s.
> > We should always use the p0s we used last time, for security's sake.
> > This is probably part of the reason why e.g. git has a list of
> > remotes for each repository.
> > 
> > Maybe you should keep a list of aliases? Or boost an identity's trust
> > when you pull from it? Really this should be WoT functionality.
> 
> I don't see why this needs to be anything more complex than aborting
> when an identifier used to look up an identity matches more than one
> identity. One need only specify the entire identity ID, perhaps with
> nickname for convenience, to always uniquely specify an identity. This
> partial matching is only for convenience.

That makes a DoS too easy, makes mistakes too easy, and generally sucks lemons 
for both security and usability.
> 
> For local identities it should be really easy for someone to figure out
> which one they mean because the search space is very limited, and they
> created every identity in it. For remote identities it might involve
> more investigation.
> 
> I think that making sure the identifier refers to the identity they want
> is the user's responsibility, not the software's responsibility. All the
> software has to do is halt if the user is anything less than specific
> enough to be exact.

Git already HAS this functionality. A git repository has a list of remotes by 
nickname. Each remote corresponds to a specific external repository URL. That's 
all I'm asking for.
> 
> The only possible problem I see with this is people pasting nicknames
> with maliciously indistinguishable UTF-8 characters intended to
> impersonate another identity. The solution to that is: "Type the
> nickname yourself or check/include the identity ID."

More dubious security issues for no reason. :(

git remote add operhiem1 operhiem1/fred
 Look it up at *this* point
git pull operhiem1
 Use the full URL (public key / USK / WoT identity) that we added.
> 
> >>> [snip]
> >>> I think such a function is mandatory for WOT anyway: There can be
> >>> multiple identities with the same nickname but the UI needs to
> >>> display unique nicknames. The de-facto solution for that is to
> >>> amend the nickname by including "@ >>> enough to make it unique>". Freetalk does this already in its own
> >>> code. Instead WOT should compute those amended nicknames and
> >>> store them.
> >> 
> >> I'd be fine with adding this as a "DisplayNickname" field or
> >> something. It seems like a useful supplement to identicons.
> 
> One thing I don't like about this way of handling nicknames is that they
> can change, and it's confusing when someone's name changes. If there is
> "person@AB" and I'm seeing them as "person@A" and "person@AC" comes
> along I have to go back and check which one is the "person@A" I knew
> from before. However, identicons and displaying the entire identity ID
> on a details page are enough that I don't think it's something worth
> looking into right now.
> 
> > Right, managed locally, with older nicks and higher trust nicks
> > taking precedence. Or something like that?
> 
> I prefer the policy of: "Refuse to perform any ambiguous operation. Do
> not jump to assumptions about the user's intent. Being surprising is
> bad." I see no reason to build some system with a complex set of rules
> and assumptions when requiring the user to be more specific is easier to
> program and easier to understand.

And make it trivial for anyone to make developer's lives a PITA, even when we 
have enough information to deal with the problem transparently.
> 
> It's worth noting that with the "fn-" commands URIs are in some cases
> saved in full USK form, so they only resolve once. Perhaps it would be
> good to have the built-in commands do something similar with setting
> paths in .hg/hgrc. (Including comments to make it clear what identifier
> resolved to the USK.) That way an identifier need only resolve once,
> after which it becomes a path which is always the same identity.

Exactly.
> 
> > DSCMs have security requirements...
> 
> Yes. Usi

Re: [freenet-dev] Infocalypse WoT Usage

2013-08-01 Thread Matthew Toseland
On Wednesday 31 Jul 2013 17:00:50 Arne Babenhauserheide wrote:
> Am Mittwoch, 31. Juli 2013, 15:50:17 schrieb Matthew Toseland:
> > Okay. The difficulty here is that there might be more than one p0s. We 
> > should always use the p0s we used last time, for security's sake. This is 
> > probably part of the reason why e.g. git has a list of remotes for each 
> > repository.
> 
> You can set explicit paths per repository ([paths] heading in REPO/.hg/hgrc). 
> and IIRC clone does this using the identities USK. So when you clone a 
> repository, the default pull path will always lead to the same repository.

Right, but what about pulling from a repository other than the origin/default? 
I may regularly review and merge code from a handful of other repositories and 
push it into "my" repository. I need to know when I do "git pull operhiem1", or 
the equivalent hg command, it pulls from the same repo as last time.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-07-31 Thread Steve Dougherty
On 07/31/2013 10:50 AM, Matthew Toseland wrote:
> On Wednesday 31 Jul 2013 00:01:05 Steve Dougherty wrote:
>> On 07/30/2013 05:45 PM, xor wrote:
>>> On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote: 
>>> [snip]
>>> How do you obtain the list of identities which you offer
>>> the user to chose from? You should use GetIdentitiesByScore with
>>> positive score filter (and context filter "Infocalypse", I think
>>> it supports that as well). Where do you present him with the
>>> list? Ideally, the UI which shows the list should pass through
>>> the ID so you don't have to filter by nickname.
>> 
>> There is no list to choose from. The user types something like "hg
>> pull freenet:p0s/WoT" and Infocalypse resolves it to a URI (not
>> necessarily one in the same subspace) and fetches it.
> 
> Okay. The difficulty here is that there might be more than one p0s.
> We should always use the p0s we used last time, for security's sake.
> This is probably part of the reason why e.g. git has a list of
> remotes for each repository.
> 
> Maybe you should keep a list of aliases? Or boost an identity's trust
> when you pull from it? Really this should be WoT functionality.

I don't see why this needs to be anything more complex than aborting
when an identifier used to look up an identity matches more than one
identity. One need only specify the entire identity ID, perhaps with
nickname for convenience, to always uniquely specify an identity. This
partial matching is only for convenience.

For local identities it should be really easy for someone to figure out
which one they mean because the search space is very limited, and they
created every identity in it. For remote identities it might involve
more investigation.

I think that making sure the identifier refers to the identity they want
is the user's responsibility, not the software's responsibility. All the
software has to do is halt if the user is anything less than specific
enough to be exact.

The only possible problem I see with this is people pasting nicknames
with maliciously indistinguishable UTF-8 characters intended to
impersonate another identity. The solution to that is: "Type the
nickname yourself or check/include the identity ID."

>>> [snip]
>>> I think such a function is mandatory for WOT anyway: There can be
>>> multiple identities with the same nickname but the UI needs to
>>> display unique nicknames. The de-facto solution for that is to
>>> amend the nickname by including "@>> enough to make it unique>". Freetalk does this already in its own
>>> code. Instead WOT should compute those amended nicknames and
>>> store them.
>> 
>> I'd be fine with adding this as a "DisplayNickname" field or
>> something. It seems like a useful supplement to identicons.

One thing I don't like about this way of handling nicknames is that they
can change, and it's confusing when someone's name changes. If there is
"person@AB" and I'm seeing them as "person@A" and "person@AC" comes
along I have to go back and check which one is the "person@A" I knew
from before. However, identicons and displaying the entire identity ID
on a details page are enough that I don't think it's something worth
looking into right now.

> 
> Right, managed locally, with older nicks and higher trust nicks
> taking precedence. Or something like that?

I prefer the policy of: "Refuse to perform any ambiguous operation. Do
not jump to assumptions about the user's intent. Being surprising is
bad." I see no reason to build some system with a complex set of rules
and assumptions when requiring the user to be more specific is easier to
program and easier to understand.

It's worth noting that with the "fn-" commands URIs are in some cases
saved in full USK form, so they only resolve once. Perhaps it would be
good to have the built-in commands do something similar with setting
paths in .hg/hgrc. (Including comments to make it clear what identifier
resolved to the USK.) That way an identifier need only resolve once,
after which it becomes a path which is always the same identity.

> DSCMs have security requirements...

Yes. Using a VCS that can sign commits is helpful here.



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-07-31 Thread Arne Babenhauserheide
Am Mittwoch, 31. Juli 2013, 15:50:17 schrieb Matthew Toseland:
> Okay. The difficulty here is that there might be more than one p0s. We should 
> always use the p0s we used last time, for security's sake. This is probably 
> part of the reason why e.g. git has a list of remotes for each repository.

You can set explicit paths per repository ([paths] heading in REPO/.hg/hgrc). 
and IIRC clone does this using the identities USK. So when you clone a 
repository, the default pull path will always lead to the same repository.

Best wishes,
Arne
--
A man in the streets faces a knife.
Two policemen are there it once. They raise a sign:

“Illegal Scene! Noone may watch this!”

The man gets robbed and stabbed and bleeds to death.
The police had to hold the sign.

…Welcome to Europe, citizen. Censorship is beautiful.

   ( http://draketo.de/stichwort/censorship )




signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Infocalypse WoT Usage

2013-07-31 Thread Matthew Toseland
On Wednesday 31 Jul 2013 00:01:05 Steve Dougherty wrote:
> On 07/30/2013 05:45 PM, xor wrote:
> > On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote:
> >> At p0s' request here's some information about how Infocalypse currently
> >> uses WoT.
> >>
> >> Infocalypse sets a "vcs" context on identities when they create a
> >> repository, and inserts a list of repositories under the identity's
> >> subspace at /vcs/. 
> > 
> > "VCS" as in "Version control system" is a general term and hg/Infocalypse 
> > for 
> > sure is not the only one.
> 
> This is the intent. OThere are fields to specify what VCS is being used
> in both pull requests and the repository lists. One of the initial
> design goals was to allow other source control systems to add support
> for Freenet in the same way. I hope for the Infocalypse web UI Fred
> plugin to be VCS agnostic so that it could be used with anything that
> communicates with it properly over FCP. I guess that makes the name wrong.

That sounds interesting.
> 
> > I think you should use "Infocalypse" as context name and as part of the URI.
> > This would be coherent with "Freetalk" as Freetalk context name and URI 
> > subspace and "WebOfTrust" as WOT subspace.
> 
> True, but as I say above this is intended for flexibility. Maybe it's
> not appropriate?
> 
> > [snip]
> >> To find remote identities it first
> >> attempts to use LessCrappyWebOfTrust's support for
> >> GetIdentitiesByPartialNickname. [0] If that fails, it looks for an exact
> >> identity ID with GetIdentity. 
> > 
> > At first look (and this is important, there is a second look below as 
> > well), 
> > this does not sound fine. The primary key for an identity, i.e. the primary 
> > object which identities it uniquely, is the ID. You should store identities 
> > by 
> > ID and identify them by ID. NOT by nickname.
> 
> I do store identities to the configuration file by ID. Any usage of
> nickname is user-facing such as being specified in a configuration file
> as part of a path or on the command line.
> 
> > You can then just include the ID in the "Infocalypse address" of the 
> > identity 
> > similar to Freetalk: Freetalk does "@.freetalk".
> > Where do you get the nicknames from? The source where you get them from 
> > should 
> > provide you with the ID.
> 
> I see no reason to do this. The ability to look up identities as
> described should be enough.
> 
> > And WOT itself should be the source of remote identities:
> > For example with Freetalk, we want to receive messages from everyone, so we 
> > obtain all identities with positive score (= positive rating "you are not a 
> > spammer") by using GetIdentitiesByScore with chosing positive score as 
> > filter.
> 
> I don't care about an identity's score in this project. Pulling from an
> identity is only done manually.
> 
> > HOWEVER there is the second look: 
> > I suppose version control does NOT imply fetching stuff from ALL identities 
> > which have a positive score from WOT.  I suppose the user selects a few 
> > identities to fetch from.
> 
> Yes.
> 
> > How do you obtain the list of identities which you offer the user to chose 
> > from? You should use GetIdentitiesByScore with positive score filter (and 
> > context filter "Infocalypse", I think it supports that as well). Where do 
> > you 
> > present him with the list? Ideally, the UI which shows the list should pass 
> > through the ID so you don't have to filter by nickname.
> 
> There is no list to choose from. The user types something like "hg pull
> freenet:p0s/WoT" and Infocalypse resolves it to a URI (not necessarily
> one in the same subspace) and fetches it.

Okay. The difficulty here is that there might be more than one p0s. We should 
always use the p0s we used last time, for security's sake. This is probably 
part of the reason why e.g. git has a list of remotes for each repository.

Maybe you should keep a list of aliases? Or boost an identity's trust when you 
pull from it? Really this should be WoT functionality.
> 
> > But I guess you might be using command line only so the user needs to be 
> > free 
> > to pass nicknames without ID?
> 
> Yes.
> 
> > In that case, I should probably implement "GetIdentitiesByPartialNickname".
> 
> That would be very useful not only for this project but also for
> anything that wants to have autocomplete. (Such as Freemail recipients
> in the "to" field of the web interface.)

Right, Freemail needs this too.
> 
> > I think such a function is mandatory for WOT anyway: There can be multiple 
> > identities with the same nickname but the UI needs to display unique 
> > nicknames. The de-facto solution for that is to amend the nickname by 
> > including "@". Freetalk 
> > does this already in its own code. Instead WOT should compute those amended 
> > nicknames and store them.
> 
> I'd be fine with adding this as a "DisplayNickname" field or something.
> It seems like a useful supplement to identicons.

Right, managed locally, with older nicks 

[freenet-dev] Infocalypse WoT Usage

2013-07-30 Thread xor
On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote:
> At p0s' request here's some information about how Infocalypse currently
> uses WoT.
> 
> Infocalypse sets a "vcs" context on identities when they create a
> repository, and inserts a list of repositories under the identity's
> subspace at /vcs/. 

"VCS" as in "Version control system" is a general term and hg/Infocalypse for 
sure is not the only one.
I think you should use "Infocalypse" as context name and as part of the URI.
This would be coherent with "Freetalk" as Freetalk context name and URI 
subspace and "WebOfTrust" as WOT subspace.

> To do this it uses the insert URI from
> GetOwnIdentities. It also checks for a Freemail context before trying to
> send something from the identity.

Fine.

> To find local identities it performs its own parsing on the
> GetOwnIdentities response to find them by enough of the nickname and
> identity ID to be unambiguous. 

Fine.

> To find remote identities it first
> attempts to use LessCrappyWebOfTrust's support for
> GetIdentitiesByPartialNickname. [0] If that fails, it looks for an exact
> identity ID with GetIdentity. 

At first look (and this is important, there is a second look below as well), 
this does not sound fine. The primary key for an identity, i.e. the primary 
object which identities it uniquely, is the ID. You should store identities by 
ID and identify them by ID. NOT by nickname.
You can then just include the ID in the "Infocalypse address" of the identity 
similar to Freetalk: Freetalk does "@.freetalk".
Where do you get the nicknames from? The source where you get them from should 
provide you with the ID.
And WOT itself should be the source of remote identities:
For example with Freetalk, we want to receive messages from everyone, so we 
obtain all identities with positive score (= positive rating "you are not a 
spammer") by using GetIdentitiesByScore with chosing positive score as filter.

HOWEVER there is the second look: 
I suppose version control does NOT imply fetching stuff from ALL identities 
which have a positive score from WOT.  I suppose the user selects a few 
identities to fetch from.
How do you obtain the list of identities which you offer the user to chose 
from? You should use GetIdentitiesByScore with positive score filter (and 
context filter "Infocalypse", I think it supports that as well). Where do you 
present him with the list? Ideally, the UI which shows the list should pass 
through the ID so you don't have to filter by nickname.

But I guess you might be using command line only so the user needs to be free 
to pass nicknames without ID?

In that case, I should probably implement "GetIdentitiesByPartialNickname". 
I think such a function is mandatory for WOT anyway: There can be multiple 
identities with the same nickname but the UI needs to display unique 
nicknames. The de-facto solution for that is to amend the nickname by 
including "@". Freetalk 
does this already in its own code. Instead WOT should compute those amended 
nicknames and store them.
They would also be suitable as Freemail addresses.

> It also checks that Freemail recipients
> have a Freemail context.

Good.

> It would be useful to publish a property containing the edition of the
> repository list. A property would allow that information to propagate
> through WoT, instead of boostrapping by fetching edition 0 and storing
> the latest known edition. Using a property is currently not practical
> because setting any property triggers a trust list insert. There is a
> bug for this. [1]

I will take care of implementing this in ~1 month I suppose. It is a suitable 
optimization for doing after event-notifications, and event-notification will 
take up the month.

Thank you.

> 
> [0]
> https://github.com/tmarkus/LessCrappyWebOfTrust/blob/master/src/main/java/pl
> ugins/WebOfTrust/fcp/GetIdentitiesByPartialNickname.java#L25 [1]
> https://bugs.freenetproject.org/view.php?id=5789


Re: [freenet-dev] Infocalypse WoT Usage

2013-07-30 Thread Steve Dougherty
On 07/30/2013 05:45 PM, xor wrote:
> On Tuesday, July 30, 2013 02:38:28 PM Steve Dougherty wrote:
>> At p0s' request here's some information about how Infocalypse currently
>> uses WoT.
>>
>> Infocalypse sets a "vcs" context on identities when they create a
>> repository, and inserts a list of repositories under the identity's
>> subspace at /vcs/. 
> 
> "VCS" as in "Version control system" is a general term and hg/Infocalypse for 
> sure is not the only one.

This is the intent. OThere are fields to specify what VCS is being used
in both pull requests and the repository lists. One of the initial
design goals was to allow other source control systems to add support
for Freenet in the same way. I hope for the Infocalypse web UI Fred
plugin to be VCS agnostic so that it could be used with anything that
communicates with it properly over FCP. I guess that makes the name wrong.

> I think you should use "Infocalypse" as context name and as part of the URI.
> This would be coherent with "Freetalk" as Freetalk context name and URI 
> subspace and "WebOfTrust" as WOT subspace.

True, but as I say above this is intended for flexibility. Maybe it's
not appropriate?

> [snip]
>> To find remote identities it first
>> attempts to use LessCrappyWebOfTrust's support for
>> GetIdentitiesByPartialNickname. [0] If that fails, it looks for an exact
>> identity ID with GetIdentity. 
> 
> At first look (and this is important, there is a second look below as well), 
> this does not sound fine. The primary key for an identity, i.e. the primary 
> object which identities it uniquely, is the ID. You should store identities 
> by 
> ID and identify them by ID. NOT by nickname.

I do store identities to the configuration file by ID. Any usage of
nickname is user-facing such as being specified in a configuration file
as part of a path or on the command line.

> You can then just include the ID in the "Infocalypse address" of the identity 
> similar to Freetalk: Freetalk does "@.freetalk".
> Where do you get the nicknames from? The source where you get them from 
> should 
> provide you with the ID.

I see no reason to do this. The ability to look up identities as
described should be enough.

> And WOT itself should be the source of remote identities:
> For example with Freetalk, we want to receive messages from everyone, so we 
> obtain all identities with positive score (= positive rating "you are not a 
> spammer") by using GetIdentitiesByScore with chosing positive score as filter.

I don't care about an identity's score in this project. Pulling from an
identity is only done manually.

> HOWEVER there is the second look: 
> I suppose version control does NOT imply fetching stuff from ALL identities 
> which have a positive score from WOT.  I suppose the user selects a few 
> identities to fetch from.

Yes.

> How do you obtain the list of identities which you offer the user to chose 
> from? You should use GetIdentitiesByScore with positive score filter (and 
> context filter "Infocalypse", I think it supports that as well). Where do you 
> present him with the list? Ideally, the UI which shows the list should pass 
> through the ID so you don't have to filter by nickname.

There is no list to choose from. The user types something like "hg pull
freenet:p0s/WoT" and Infocalypse resolves it to a URI (not necessarily
one in the same subspace) and fetches it.

> But I guess you might be using command line only so the user needs to be free 
> to pass nicknames without ID?

Yes.

> In that case, I should probably implement "GetIdentitiesByPartialNickname".

That would be very useful not only for this project but also for
anything that wants to have autocomplete. (Such as Freemail recipients
in the "to" field of the web interface.)

> I think such a function is mandatory for WOT anyway: There can be multiple 
> identities with the same nickname but the UI needs to display unique 
> nicknames. The de-facto solution for that is to amend the nickname by 
> including "@". Freetalk 
> does this already in its own code. Instead WOT should compute those amended 
> nicknames and store them.

I'd be fine with adding this as a "DisplayNickname" field or something.
It seems like a useful supplement to identicons.

> They would also be suitable as Freemail addresses.
> 
>> It also checks that Freemail recipients
>> have a Freemail context.
> 
> Good.
> 
>> It would be useful to publish a property containing the edition of the
>> repository list. A property would allow that information to propagate
>> through WoT, instead of boostrapping by fetching edition 0 and storing
>> the latest known edition. Using a property is currently not practical
>> because setting any property triggers a trust list insert. There is a
>> bug for this. [1]
> 
> I will take care of implementing this in ~1 month I suppose. It is a suitable 
> optimization for doing after event-notifications, and event-notification will 
> take up the month.
> 
> Thank you.
> 
>>
>> [0]
>> 

[freenet-dev] Infocalypse WoT Usage

2013-07-30 Thread Steve Dougherty
At p0s' request here's some information about how Infocalypse currently
uses WoT.

Infocalypse sets a "vcs" context on identities when they create a
repository, and inserts a list of repositories under the identity's
subspace at /vcs/. To do this it uses the insert URI from
GetOwnIdentities. It also checks for a Freemail context before trying to
send something from the identity.

To find local identities it performs its own parsing on the
GetOwnIdentities response to find them by enough of the nickname and
identity ID to be unambiguous. To find remote identities it first
attempts to use LessCrappyWebOfTrust's support for
GetIdentitiesByPartialNickname. [0] If that fails, it looks for an exact
identity ID with GetIdentity. It also checks that Freemail recipients
have a Freemail context.

To find a repository when given something like "hg pull
freenet:operhiem1/pyProbe", it will find operhiem1 as a remote identity,
fetch its /vcs/, match the name, and return the resulting URI.

It would be useful to publish a property containing the edition of the
repository list. A property would allow that information to propagate
through WoT, instead of boostrapping by fetching edition 0 and storing
the latest known edition. Using a property is currently not practical
because setting any property triggers a trust list insert. There is a
bug for this. [1]

Thanks,
operhiem1

[0]
https://github.com/tmarkus/LessCrappyWebOfTrust/blob/master/src/main/java/plugins/WebOfTrust/fcp/GetIdentitiesByPartialNickname.java#L25
[1] https://bugs.freenetproject.org/view.php?id=5789



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl