[PP-main] please read - revised (much better) spec
lists at itsg.net.au
lists at itsg.net.au
Thu Mar 16 02:53:49 CET 2000
find my comments below.
On Thu, 16 Mar 2000, Nick Lothian wrote:
> Just a suggestion, so don't take this as a flame: When you write these
> documents, could you use words rather than abbreviations (at least
> sometimes), and possibly some capital letters? It would make it much easier
> to read.
sure. no offence taken (for any feedback you give, not just that).
> Anyway, I think that peer press shouldn't worry about the content-authors -
> or at least about the submission process from them.
i totally agree.
> The individual content
> producing sites should worry about that, using whatever method they choose.
> For instance Slashdot has it's story posters, ZDNet has paid journalists,
> and kuro5hin will let anyone submit a story.
> The individual sites then decide what stories to submit to the peer-press
> system, using whatever method is appropriate for them (eg, kuro5hin might
> use it's story moderation features to decide some should not be submitted,
> while Slashdot might submit all its stories).
we seem to be headed in exactly the same direction so far.
> The story is submitted by placing it in a XML file, which anyone (not just
> some "peer-press" server) can poll for.
sure. nowhere in the spec did i specify that only the ppn
central server could retrieve the XML document. however, if an AF site
wants to make sure that the content has been "trustified", then
they should probably wait 15 minutes to get it from their local MS.
> Now comes the added functionality, that we should have, but the process up
> to here should not depend on.
> The peer-press server recieves the file (by polling, by HTTP-Post, email, or
> whatever interface), with the content (or URL to the content if it is a
> large binary file), the submitting site, a unique ID to identify it, and the
> authors identification (It should also have stuff like an abstract, a
> content, possibly something like a PIC rating). The authors identification
> should not rely on Peer-Press, but should be a way to uniquly identify them.
> I believe a system similar to avagato trust certificates was suggested, and
> I would support something like this, provided it was optional.
ok, nice idea. a couple of questions that i feel i thought
through and answered (albeit not perfectly):
1. where does the unique document id come from?
2. where does the authors id come from?
3. how does the PPN access these details?
4. who is responsible for the PIC rating?
5. who "moderates" the PIC rating?
> The peer-press acts as an aggregator, to make it easy for content-users
> (affiliates) to find content. Affiliates then get the content (via HTTP
> polling, flux, mail, again - whatever interface we choose to support), along
> with a trust rating, which is determinted by the site it came from, and the
oh, ok. i see where you're going. a trust rating derived from the
CA's trust rating and the AF site's trust rating. my questions above still
stand though 8^)
> The affiliate sites can use this to automatically post items on their site
> with no human intervention, by depending on the trust rating.
i think this could easily be added into the spec i have designed without
any hassles. i know what i have sent to the list is far from perfect,
but i really think it is a workable solution. i do appreciate the time
you have taken to provide some feedback on it nick, but feel you might
be being a little hard on it - especially seeings as:
1. it basically does everything you want the system to do.
2. it is a draft.
3. i think it would make a good short term solution because it would
be extremely easy to implement. we're not talking about re-inventing
the wheel here. maybe it could be done while another working group
creates version 2 - which skirts around the failures that would be
discovered in this system.
4. in the absense of an all encompassing long term solution - it's better
than having nothing. if anyone else can do better, please do. then
you can get rid of me 8^)
*if anyone thinks i'm wrong on any of these issues, please set me
> That's my idea, at least. I think someone with more experience than me
> should talk about how we figure out the user's identity, and determine the
> trust rating.
like you said to me at the start of your email, please don't take this
as a flame. i think this idea has a lot of potential, and would to see
some sort of "roadmap" developed soon. too many ideas in the community
never seem to make it off the ground - and i would be upset if that
happened to this one. maybe i am just being too hasty.
> ----- Original Message -----
> From: <avi at itsg.net.au>
> To: <peerpress-main at lists.styx.net>
> Sent: Thursday, March 16, 2000 10:00 AM
> Subject: [PP-main] please read - revised (much better) spec
> > dear list members,
> > i have created a new spec for your enjoyment.
> > it is *much* better than the last one i posted, so please read it
> > even if you hated my last one 8^)
> > any questions or feedback would sincerely be appreciated.
> > enjoy your day,
> > avi
> > ---
> > http://www.geocities.com/peerpress_au/ppn_r2.png
> > * legend
> > + ppn - peer press network
> > + ca - content author (red)
> > + wi - web interface
> > + af - affiliate (aqua)
> > + cu - content user, an end user of an af (white)
> > + cs - central server (green)
> > + ms - mirror server (blue)
> > * 0 (once only action)
> > + if ca isn't currently registered with ppn, they do so through
> > the wi.
> > * 1
> > + ca logs into wi to "create new content". they fill out
> > a form that allows them to select:
> > - which af is going to help them publish it
> > - which category the content belongs to
> > + they then receive a username/hash pair, which is usable once
> > only for that particular piece of content.
> > + the ca can repeat this step as many times as they like.
> > any username/hash pairs that are unused after 7 days are
> > discarded from the system.
> > * 2
> > + the ca submits their content to a ppn af, along with the
> > username/hash pair and the category the content should be published
> > under.
> > * 3
> > + the af moderates the submitted content as usual, and decides
> > whether or not it is good enough to put their name on.
> > if they decide that it is, but think the category is not
> > appropriate (ie. story about "war in bosnia" classed as
> > sports -> team -> basketball, or cool mp3 of jungle techno classed
> > as audio -> music -> classical -> romantic) they may notify the
> > ca to change it. the ca must then go to the wi, change the
> > category for that username/hash pair and notify the af.
> > otherwise, the af places the content in a file at
> > http://www.pnp-af-address.com/ppn_new.xml, which conforms
> > to the ppn xml dtd (any takers on that one?)
> > * 4
> > + every n minutes (15?) the ppn cs polls all the af sites
> > for new content from the above file. if:
> > + the username/hash pair for the content *does not* exist in the
> > cs database an email is generated
> > - to the af site asking them to remove it form their xml file
> > - to the ca to notify them that someone was trying to submit
> > content under their details (?)
> > + the username/hash pair for the content *does* exist in the
> > cs database, a check is made
> > - to see if the correct af site is trying to publish the content.
> > if not, an email is generated to both the ca and the real af,
> > and the trust of the offending af drops.
> > - to see if the category in the submitted xml matches the category
> > selected by the ca. if it doesn't, the content is rejected
> > and the ca and the af are notified.
> > if both these checks are passed, the content is placed into the
> > database with its status marked as "awaiting verification".
> > the ca is notified via email when this occurs.
> > * 5
> > + the ca uses logs into the wi the check their content.
> > if they are satisfied with it (ie. it hasn't been tampered with),
> > they use a form to modify the content status to "distribute".
> > + any content whose status is not modified to "distribute"
> > within 72 hours of being marked as "awaiting verification" will
> > be removed from the cs.
> > * 6
> > + every n minutes (15?) the cs notifies all ms's about any content
> > that they don't know about.
> > + this notification will mostly involve the content that has been
> > update in the last n minutes, however:
> > - if the ms is brand new, all the content that has been added
> > since the database was copied to it will be updated.
> > - if the ms has been offline or uncontactable, all the content
> > added since the last update will be transferred to it.
> > + (during this process, the cs also grabs the last time that a
> > particular af got a content update, and tells all the other
> > ms's. this is so if an ms goes offline or becomes uncontactable
> > an af site can simply change the setting in their config
> > to another ms, and not worry about doubling up on content.
> > see * 7 if this doesn't make sense yet).
> > * 7
> > + af sites poll their local ms for new content via an easy to setup
> > script written in perl/php that runs as a cron job.
> > basically, they enter some parameters into a config file
> > (username,password,fqdn of local ms) and the script connects to
> > and returns any data sent to it. (obviously, this will only be
> > content that the af site has selected to receive through the wi)
> > (at this point, the ms stores the date/time of when the afusername
> > got all the latest content, see comment in * 6)
> > this will be xml data complying with the ppn xml dtd which the af
> > can then parse and insert into their content queue, just as if
> > someone has submitted the content to the site.
> > * 8
> > + the af sites receiving new content "moderate" it as usual,
> > and choose whether or not to include it.
> > * 9
> > + cu's enjoy the content provided by ppn through their af.
> > ---
> > * considerations
> > + anywhere this spec talks about notifying anyone via email,
> > substitute your favourite electronic messaging system.
> > (email,icq/aim/etc,mobile phone sms,paging).
> > + a trust metric will need to be used to stop colloborating
> > ca's and af's abusing the system.
> > + technical (implementation) details will be created by me shortly
> > for this document (if the feedback is good). this will include
> > a list of jobs that will need to be done to achieve a working
> > version of ppn. (which i consider do-able in 3 months if the interest
> > is there, and we have a couple of people dedicated to seeing that it
> > happens.)
More information about the Peerpress-main