From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VHV0N-0003zR-Eq for bitcoin-development@lists.sourceforge.net; Thu, 05 Sep 2013 08:33:31 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.41 as permitted sender) client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f41.google.com; Received: from mail-oa0-f41.google.com ([209.85.219.41]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VHV0M-0005aH-FK for bitcoin-development@lists.sourceforge.net; Thu, 05 Sep 2013 08:33:31 +0000 Received: by mail-oa0-f41.google.com with SMTP id j6so1852254oag.28 for ; Thu, 05 Sep 2013 01:33:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.118.41 with SMTP id kj9mr5505134oeb.31.1378370004787; Thu, 05 Sep 2013 01:33:24 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.80.165 with HTTP; Thu, 5 Sep 2013 01:33:24 -0700 (PDT) In-Reply-To: <2DE404E4-446E-41F4-8ECF-B312EE42D067@grabhive.com> References: <2DE404E4-446E-41F4-8ECF-B312EE42D067@grabhive.com> Date: Thu, 5 Sep 2013 10:33:24 +0200 X-Google-Sender-Auth: RdRdTpx1M0UrzIeWsgvrFhJ9WgA Message-ID: From: Mike Hearn To: Wendell Content-Type: multipart/alternative; boundary=047d7b3a99ee812d5004e59ec600 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VHV0M-0005aH-FK Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Social network integration (brainstorm) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 08:33:31 -0000 --047d7b3a99ee812d5004e59ec600 Content-Type: text/plain; charset=UTF-8 > > Since this process would necessarily be somewhat manual and would of > course be "undone" anytime the user changed his/her profile image, it is > probably not a solution for everyone. I guess these days most Facebook/G+/Twitter users are logged in from their smartphone , so you'd implement it as a mobile app that gets API access via the standard mobile frameworks. The UI flows for this are highly optimised and very slick. Once you have API access to read/write the users profile picture, your app can just wake up from time to time and check if the users profile picture has changed. If it did, download the highest resolution available, rewatermark and reupload. The main sticking point I can see is that the user might end up losing comments or likes on their primary photo, which would upset some people, and they might end up with duplicates if the old one was not erased. The Facebook API docs are notoriously poor - it's unclear to me whether an app can edit a photo after it was uploaded, or whether it can only create new ones (deleting photos requires whitelisting by Facebook). To read the users watermarked address requires no API access or account, though. Probably you wouldn't want to watermark an actual Bitcoin address or key. The capacity of social network photos to carry stegod data is very low due to the incredibly high compression they go through. More likely you'd encode a very short URL which contains a payment request and then users would rotate their key from time to time at the hosting site. --047d7b3a99ee812d5004e59ec600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since this process would necessarily be somewhat manual and would of course= be "undone" anytime the user changed his/her profile image, it i= s probably not a solution for everyone.

I guess these days most Facebook/G+/Twitter users are logged in from their = smartphone , so you'd implement it as a mobile app that gets API access= via the standard mobile frameworks. The UI flows for this are highly optim= ised and very slick. Once you have API access to read/write the users profi= le picture, your app can just wake up from time to time and check if the us= ers profile picture has changed. If it did, download the highest resolution= available, rewatermark and reupload.=C2=A0

The main sticking point I can see is that the user migh= t end up losing comments or likes on their primary photo, which would upset= some people, and they might end up with duplicates if the old one was not = erased. The Facebook API docs are notoriously poor - it's unclear to me= whether an app can edit a photo after it was uploaded, or whether it can o= nly create new ones (deleting photos requires whitelisting by Facebook).

To read the users watermarked address requires no API a= ccess or account, though.

Probably you wouldn'= t want to watermark an actual Bitcoin address or key. The capacity of socia= l network photos to carry stegod data is very low due to the incredibly hig= h compression they go through. More likely you'd encode a very short UR= L which contains a payment request and then users would rotate their key fr= om time to time at the hosting site.
--047d7b3a99ee812d5004e59ec600--