1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANEZrP2ph9SM6kUdTXooZ2nqKD4LweWsgVEdssiftNdBmcP+_w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
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.</blockquote><div><br></div><div>
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</div>
<div><br></div><div>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).</d=
iv>
<div><br></div><div>To read the users watermarked address requires no API a=
ccess or account, though.</div><div><br></div><div>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.</div>
</div></div></div>
--047d7b3a99ee812d5004e59ec600--
|
