Difference between revisions of "ListenLog Meeting Notes"

From Project VRM
Jump to navigation Jump to search
(editing...)
Line 66: Line 66:
  
 
==1/20==
 
==1/20==
* There is a core set of things to figure out to proceed with this project. Other things can and should be considered, but aren't critical to building the core aspects
+
* There is a core set of things to figure out to proceed with this project. We'll focus on those:
** What data are we capturing
+
** What data will we capture?
** What format are we sending and storing the data in
+
** What format will we send and store the data in?
** How is this data being transmitted and stored
+
** How is this data being transmitted and stored?
** How do we maintain integrity, privacy, and required minimum of control (e.g. "delete my data")
+
** How do we maintain integrity, privacy, and provide the required minimum of user control (e.g. "delete my data")?
** How do we assign identity
+
** How do we assign or associate identity?
 
 
* XDI can be used to transmit and/or store; X3 looks promising
 
  
 
* In discussing data capture, Keith argued for being minimal and conservative and providing a mechanism for extending
 
* In discussing data capture, Keith argued for being minimal and conservative and providing a mechanism for extending
Line 80: Line 78:
 
* XRI be resolved / discoverability
 
* XRI be resolved / discoverability
  
XRI = identifier - resolvable to an XDI endpoint
+
* XDI can be used to transmit and/or store; X3 looks promising
XDI dictionary - like an XML schema
+
* XRI = identifier - resolvable to an XDI endpoint
 
+
* XDI dictionary - like an XML schema
XRI authority resolution server (open XRI)
+
* XRI authority resolution server (open XRI)
- community iname registry
+
** community iname registry
- inumber (this is how you handle reassignment)
+
** inumber (this is how you handle reassignment)
- are we doing this on their behalf or are we doing self-registration?
+
** At what level will we register?
 
+
** How will we maintain this registry?
xri synonyms is the answer?
+
** How will other applications that write to LL handle XRI? Will they resolve to their own server?  
 
+
**What about dupes?
iname registration for digital identity
+
***xri synonyms is the answer?
- might not need an icard selector on the iphone
+
** Use iname registration for digital identity?
 +
*** might not need an icard selector on the iphone
 +
*** Simpler way?

Revision as of 22:19, 21 January 2009

Below are meeting notes and ongoing issues and action item lists. For a detailed description of ListenLog, visit the main ListenLog page.

1/12

Parking Lot


  • Where is data stored (by default)? Does it sync to a local store or just stream out?
  • Is there any concern from collaboration stations and partners that there's no exclusive access to data / analytics?
  • What data do we capture? Application behavior data in addition to basic listen data? What about rating data? Location data?
    • Should the standard by minimal for extensibility vs. maximal for enhanced value/functionality
    • Privacy concerns (EFF Chair Brad Templeton)
  • Security / encryption on the stored data? Which bits?
  • How best to communicate and promote the ListenLog concept and where the key benefits and differentiators are? How do we address naysayers and differentiate from alternative approaches, e.g. APML?
  • How do we do identity? How do we make it swappable? Do we use icards, openID, Oauth?
  • How do we start the service without identity? (e.g. access to device ID?)
  • Do users have control over what's stored?
  • What's the absolute minimum of device-side functionality?
    • Opt-out(?)
    • Change repository
    • Assign identity
  • Where does legal and TOS come in? (see rights and contracts below)
  • Does anyone enforce standards compliance?
  • Who does the work / coding?
    • PRX + who?
  • Do we think about revenue / sustainability? PRX has two roles here - one to build codebase and standards for storage, the other to think about services and how we'd use the data.
  • Do we do opt out for data capture? (probably yes)
  • Do we provide "public by default," e.g. ubiquitious, anonymous access to the data out of the box (probably no)
  • Can we open source iphone bit? Publicly available libraries?
  • What's in the first release?
    • Should we provide ability for users to release data? How and to whom? What capacity for sharing? What terms? Anon vs. nonanon?
  • Does there need to be database legal protection underlying data rights access to drive user terms?

1/13

  • How do we make the data inherently more anonymous?
    • Match account data between logs
    • Make timestamp and LAT-LONG fuzzy?
  • What data rights can a user authorize for third parties?
    • propagation rights (the grantee can't extend to someone else)
    • public rights vs. directed/granted rights (e.g. for anyone to use vs. for specific entity to use)
      • anon/non-anonymous
      • Most rights issues/rats nests are associated with granted rights
    • How long you can use the data for? Keep the data?
    • Rights to cease use, remove data(?) + confirmation(?)
    • Can't use this to try and find/identify someone - reverse-engineering rights
    • commercial/non-commercial?
    • Contact me (e.g. DNC)
    • Compare to IRB
  • Contract rights
    • Investigate proactively - what is it that pandora might want to do? What is reasonable?
      • give me audio recommendations
      • use for product development
    • Don't cross-correlate/aggregate (e.g. social network correlation, Ben Laurie) - piercing identity/privacy data
    • Endorsement / assignment to my identity

Core Requirements

  • what data is going to be captured
  • where is it stored and in what format
  • how does one identify oneself / assign identity
  • what's the minimum functionality that needs to live on the device
  • what's the minimum functionality that needs to live remotely
  • additional / core functionality to prove value necessary?
  • Determine protections for communication and storage between client app and repository authenticated, encrypted, etc.

Action Items

  • Draft functional requirements
  • Doc talk to Berkman legal re: user rights / terms

1/20

  • There is a core set of things to figure out to proceed with this project. We'll focus on those:
    • What data will we capture?
    • What format will we send and store the data in?
    • How is this data being transmitted and stored?
    • How do we maintain integrity, privacy, and provide the required minimum of user control (e.g. "delete my data")?
    • How do we assign or associate identity?
  • In discussing data capture, Keith argued for being minimal and conservative and providing a mechanism for extending
  • Agreement that our proposed data, format, and services will deal with listening attention data only; both for on-demand (file) audio as well as streaming audio
  • Open question about whether Sound Exchange / RIAA requires specific formats, if so, might be nice to comply
  • XRI be resolved / discoverability
  • XDI can be used to transmit and/or store; X3 looks promising
  • XRI = identifier - resolvable to an XDI endpoint
  • XDI dictionary - like an XML schema
  • XRI authority resolution server (open XRI)
    • community iname registry
    • inumber (this is how you handle reassignment)
    • At what level will we register?
    • How will we maintain this registry?
    • How will other applications that write to LL handle XRI? Will they resolve to their own server?
    • What about dupes?
      • xri synonyms is the answer?
    • Use iname registration for digital identity?
      • might not need an icard selector on the iphone
      • Simpler way?