[PP-main] please read - revised (much better) spec
avi at itsg.net.au
avi at itsg.net.au
Thu Mar 16 01:30:22 CET 2000
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,
+ 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
+ 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.
+ the ca submits their content to a ppn af, along with the
username/hash pair and the category the content should be published
+ 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?)
+ 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.
+ 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.
+ 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).
+ 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.
+ the af sites receiving new content "moderate" it as usual,
and choose whether or not to include it.
+ cu's enjoy the content provided by ppn through their af.
+ 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
More information about the Peerpress-main