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 "<nickname>@<identity-id>.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 "@<part of identity ID long 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.

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

DSCMs have security requirements...
> 
> > 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.

Attachment: 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

Reply via email to