[PP-main] please read - revised (much better) spec

Nick Lothian Lothian.Nicholas at lmsol.com.au
Thu Mar 16 02:16:50 CET 2000


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.

Anyway, I think that peer press shouldn't worry about the content-authors -
or at least about the submission process from them. 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).

The story is submitted by placing it in a XML file, which anyone (not just
some "peer-press" server) can poll for.

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.

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
author.

The affiliate sites can use this to automatically post items on their site
with no human intervention, by depending on the trust rating.

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.

Nick


----- 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
>
https://fqdn-of-local-ms/new_content?username=afusername&password=afpassword
>     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 mailing list