Re: PUSH Definitions
Subject: Re: PUSH Definitions
From: Clark Robinson <robinsonchicago@gmail.com>
Date: 7/23/10, 17:38
To: Scott Mintz <scott.w.mintz@gmail.com>
CC: Barrett Brown <barriticus@gmail.com>

We are now past the level of systems knowledge where I feel comfortable saying much other than I don't see why this would not work.

At any rate, there is a requirement that there be authentication of the pushing blogger.

Another requirement implicated here: the widget will need to be able to distinguish home pages from specific blog posts, since it can only push the link to the latter.

Need to keep in mind that more than one blogger on a given website may have widgets.

Since only bloggers will have widgets with the push feature, there is probably not a high potential for improper pushing, and thus it might be possible to address the problem this way: the system could fairly frequently send back to each blogger a list of the posts he/she pushed, and if there has been an inauthentic push, the post in question can be derailed, and remedial measures taken (cancel the offending widget if we think it's been cloned, or suggest the blogger secure his computer when he's away from it).

There was a systems lady in Baltimore who would sometimes say to me "Clark, that's too how."  What she meant was that I should should articulate the requirement in terms of the process and the objectives, but let the programmers use their knowledge to devise the solutions.  I am not sure where the line between a requirement and a how falls in any given program feature, but the distinction is worth keeping in mind.

Also, I am kind of leery of asking our bloggers to keep track of a systems-generated code, that's a tough thing to do if you travel, work from home, (Scott has already pointed these possibilities out). I am sure you are like me and limit the number of secure programs you participate in because the number of password requirements rapidly exceeds practical ability to keep track of them.



On Fri, Jul 23, 2010 at 3:44 PM, Scott Mintz <scott.w.mintz@gmail.com> wrote:
I don't know if this is possibly, but ideally each widget can have a small adjustment in its programming specific to the website that it is installed to, so that the owner of that website would have to input a specific code in order to activate the features of the widget. The code would be randomly generated on installation and stored in the programming of the widget for matching.

For example, when someone installs the widget to their home page they may get a one-time message that says, "Please wrote down the following code, A1B2C3, which you will use in the future anytime you activate the "PUSH" features of this widget. This is the only time you will receive this code and if you forget or lose it, you will have to re-install the widget to receive a newly generated code"

This solves the problem of making sure that only the originator of posting is capable of primary pushing the post. Once this is complete, the primary push will send the links to a new group of bloggers (with their own codes embedded) along with an identifier that signals to the widget on the original posting that (1) this person has been granted the right to PUSH and (2) this person is person A and pushes by person A will go to the following bloggers (codes embedded)

Please let me know if this makes sense to you guys, and/or if there are ways to make this more concise and clear.


On Thu, Jul 22, 2010 at 6:03 PM, Clark Robinson <robinsonchicago@gmail.com> wrote:
Re: stuff highlighted in green, for the bloggers, I guess passwords are going to be necessary.  I don't think they will be necessary for the readers, unless we have a messaging system, in which case I suppose the readers will have to have passwords, also, since they will need to have a way to associate reader widget ID codes with the owners's identity in order to know how to message their buddies. I am kind of inclined to think we should go for a good push system in the first release, and be cautious about additional functionalities.


On Thu, Jul 22, 2010 at 4:12 PM, Scott Mintz <scott.w.mintz@gmail.com> wrote:
I did put in the BLOGGER revisions and will continue to do so. Also, I will re-word the PUSH definitions to include what you describe below. (In case you want to follow my thoughts, I plan on having a separate section for MESSAGING).

With regards to messages, I too have been thinking how this could be done on a server-less network. One thought that came to mind is that based on the assumption every Project PM widget hosted a particular blog has a unique ID then another widget could be given commands to ping that ID until it received back an indicator that it's active then sends a message to that widget, which could (1) be AON (all or nothing) or (2) get stored in that widget like the posting queue.

While thinking about this and the PUSH definitions it came to my attention that some mechanism, such as the previously unique coded identifiers will absolutely be necessary to ensure that someone does not incorrectly have the ability to push someone's work. IP address came to mind but that changes for people if its dynamic, if they log in from different locations, and they can also be spoofed. Maybe Barrett's people will have a good idea on this front.


On Thu, Jul 22, 2010 at 3:16 AM, Clark Robinson <robinsonchicago@gmail.com> wrote:
Go ahead and copy this stuff into the spreadsheet as a general comment. Only thing I would add, in reference to the pink highlighted text, is that the primary push blogger has to have open the post itself (as if he/she was reading comments to it), so that the push sends the URL unique to the post itself, and not the URL of the blog's home page.  This is already in the specs but maybe needs to be repeated in this context. Perhaps the widget will need to be able to distinguish homepage URLs from post-specific URLs and error-message a blogger who attempts to push a homepage URL.

Scott, did you swap the revisions you sent me yesterday into the appropriate fields in the spreadsheet, or do you need me to do that?

Also, If you can figure out a simple internal messaging system using the widget identifier codes, I would say go ahead and describe it in the spreadsheet; it does not hurt to propose stuff, and the programmer can tell us if its feasible or not.  As I said, and speaking only for myself, my goal is to get this moving, not to resolve all requirements issues, given that I don't have the requisite knowledge or experience to do that. What I can not figure out about a messaging system is how the reader would direct the message to the right person; there could easily be a milllion widgets out there, and we surely do not want to have an index with names in it for all sorts of reasons. (Too much information to store without using a server, for one thing).


On Wed, Jul 21, 2010 at 11:51 PM, Scott Mintz <scott.w.mintz@gmail.com> wrote:

Definitions:

PUSH –> There are unlimited levels of pushes (i.e. Primary, Secondary, Tertiary, etc.). Anytime a Blogger pushes a specific posting, then subsequently that blogger’s ability to push that specific posting again will cease.

Primary - A primary push occurs when a Blogger originates a post on their website and then using the Project PM widget located on that site, accesses the widget and uses the  “PUSH” function to send links along with a coded identifier to all other Bloggers that this particular person has EITHER (1) successfully invited to Project PM or (2) requested, and subsequently accepted, that the Blogger review their postings.

Secondary – A secondary push occurs when a Blogger receives a link in queue from a Primary push with a coded identified from another Blogger, and subsequent to reviewing the posting on the originating Blogger’s website, is able to use that site’s Project PM widget along with BOTH (1) the original coded identifier and (2) their own coded identifier to “PUSH” a link in queue to all Bloggers that this particular person has EITHER (1) successfully invited to Project PM or (2) requested, and subsequently accepted, that the Blogger review their postings, EXCLUDING both the post originator and any Bloggers that received the post in the primary push.

Tertiary – A tertiary push occurs with a Blogger received a link in queue from a Secondary push with a coded identifiers from BOTH (1) the primary both and (2) the secondary push, and subsequent to reviewing the posting on the originating Blogger’s website, is able to use that site’s Project PM widget along with ALL coded identifiers including their own to “PUSH” a link in queue to all Bloggers that this particular person has EITHER (1) successfully invited to Project PM or (2) requested, and subsequently accepted, that the Blogger review their postings, EXCLUDING both the post originator and any Bloggers that received the post in the primary or secondary pushes.