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

[avi at itsg.net.au]

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