allow for standard way for content (for example, a permalink) to be blogged, digged, etc.




11 years ago
10 years ago


(Reporter: (not reading, please use instead), Unassigned)



Firefox Tracking Flags

(Not tracked)


allow for standard way for content (for example, a permalink) to be blogged / shared / digg'd, etc.

I'm including things like digg and reddit here, but that might be something else.

this could be a microformat, so that content authors could add semantic data to permalinks, and then when handling that microformat, we'd launch the users blog to create a new post.

see also phil's "blog this" add-on,

and the "BlogThis" button in the google toolbar (

and clip-to-blog

One sticky point is that people often have multiple blog, and I'm not sure how that would work.  Although in mkaply's Operator add-on, you can have multiple consumers for the same microformat.

alex, dan and I chatted about this yesterday, and this bug is for continuing the discussion.

originally we discussed a "share://" protocol, but now I'm thinking microformats is the right solution.

Comment 1

11 years ago
The obvious analog to this functionality today is the mailto: URL, though that is essentially a single implementation of something we'd like to see generalized.  If one were to do this by microformat as you suggest, it's not clear to me what sort of semantic data you'd want; can you elaborate?  Just something like |class="sharable"|?
I think a microformat helps you identify what the data _is_, but it doesn't (can't; shouldn't) tell you what operations the user can perform on it.

I might want to blog a link or an event, digg a link, or re-blog an article based on my selection rather than an author's explicit "thinking ahead".  That requires two distinct pieces:

- a way to extract that data from the page in a useful structure (which will hopefully not be restricted to microformat parsing)

- a way to associate a web service or application with a verb ("share", "blog", "remember", "find others like", "send to phone", etc.) and a set of acceptable input types ("date", "event", "person", "address", "excerpt", "image", "arbitrary HTML content", "link", "I'll try anything once!", "music/audio", etc.)

I think this bug is most usefully about the latter portion, and how applications (web or desktop) can register themselves for -- and then later receive -- the kinds of content that they can accept at the user's discretion.
You need to log in before you can comment on or make changes to this bug.