#social 2017-09-07

2017-09-07 UTC
KevinMarks and cdchapman joined the channel
#
Gargron cwebber2: https://twitter.com/StarSumiaki/status/905608945208745984
#
Loqi [@StarSumiaki] @Gargron That all does sound pretty cool. Is there a "for idiots" diagram somewhere explaining the protocols and their differences?
#
@dustyweb The spec mentioned is ActivityPub, of which I'm co-editor. Super excited for this! https://www.w3.org/TR/activitypub/ https://twitter.com/Gargron/status/905605968033132545 (twitter.com/_/status/905615346916261888)
#
cwebber2 Gargron: replied, linking tho rhiaro's SWP doc
Loqi, cdchapman, xmpp-social, KevinMarks_, KevinMarks, dmitriz, tantek and eprodrom joined the channel
#
Gargron cwebber2: you asked about protocol handlers
#
Gargron you can visit web+mastodon://follow?uri=gargron@mastodon.social and it will open a follow dialog on your instance
#
Gargron you can visit web+mastodon://share?text=Blah+blah and it will open a new toot dialog on your instance with "Blah blah" pre-filled
#
Gargron that's all i got so far
#
tantek Gargron - very cool
#
tantek sounds a lot like what we've been developing as "Webactions" in the indieweb
#
tantek https://indieweb.org/webactions
#
Gargron interesting
#
jaywink How does that work in practise? Unknown protocol for me, of course. What else is needed for the follow to work?
#
tantek jaywink we have polyfills that make it work
#
tantek there are two halves to it, the buttons, and sites which can support handling them
#
jaywink But how does my bowser know what is my Mastodon instance?
#
tantek I have the first (webaction buttons) live on my site
#
tantek jaywink, that's handled by sites that can handle them going through registration
#
tantek through the UI
#
dlongley Gargron, tantek: you guys may be interested in the "web action"/"web request" approach taken by web payments and the CCG wrt credentials ...
#
dlongley i wrote a little bit about it here: https://github.com/w3c-ccg/credential-handler-api/issues/2
#
Loqi [dlongley] #2 Credential Handler registration API Shape
#
dlongley and we have a couple of demos now that work in Chrome, Firefox, and Edge
#
dlongley (and Safari if you mess with your preferences)
#
Gargron jaywink: when you open the mastodon web UI, it calls registerProtocolHandler
#
Gargron your browser asks you for permission
#
Gargron after that it will open that registered handler
#
tantek Gargron - yes that's how the webaction approach works as well
#
Gargron if you have multiple handlers the browser will give you a choice
#
tantek but with a library that any site can use to setup user-driven registration via the browser
#
dlongley http://credential-repository.demo.digitalbazaar.com/ <-- a demo of credential handler
#
dlongley http://payment-handler.demo.digitalbazaar.com/ + http://payment-merchant.demo.digitalbazaar.com/ <-- a demo of web payments
#
jaywink Ok thanks, interesting both of these ?
#
sandro I'll be very interested to see how this plays with Mastodon's end-users. Protocol handlers being missing on mobile and having a confusing install process made them seem like a non-starter to me (which is why I advocated the special-domain approach instead). Maybe end-users are more tolerant than I expected.
#
dlongley perhaps similar or same general principles for social web actions -- at least at the core.
#
dlongley website X wants something that website Y can provide, and the browser plays a "mediator" role to make it happen.
#
dlongley website Y plays a "handler" role.
#
dlongley i also thought it was interesting that you guys were discussing certain types of read-only/etc. widgets ... as we briefly discussed that in the web payments work for obtaining information like shipping addresses from third party sites
#
xmpp-social [ajordan] I always thought it was a bummer WebIntents and projects like it didn't make it
#
tantek dlongley that's basically how I conceptuallized webactions in the original blog post here: http://tantek.com/2011/220/b1/web-actions-a-new-building-block
#
Loqi [Tantek Çelik] Web Actions: Identifying A New Building Block For The Web
#
sandro indeed -- this is all trying to work around the absence of webintents
#
tantek and then we had several folks try experimenting and building it on their own websites
#
dlongley tantek: yup, i was just reading that before i popped in here -- and saw it was a good fit.
#
tantek sandro - webintents never actually worked
#
tantek so saying "work around the absence of webintents" is a bit like "work around the absence of a magical solution"
#
dlongley there's a post mortem paul kinlan wrote somewhere on webintents and what failed
#
xmpp-social [ajordan] tantek: I'm sure there were good reasons for it failing, for sure
#
dlongley trying to do too much -- and not keeping use cases focused and the scope of what the feature could do limited was an issue
#
xmpp-social [ajordan] All I'm saying is that it's a bummer
#
tantek dlongely - I was involved with a lot of the early feedback to paul kinlan of the problems with web intents
#
Gargron protocol handler is not ideal but isn't that what gmail does too?
#
tantek ajordan, to be summarize bluntly, it focused on plumbing, and not UX
#
xmpp-social [ajordan] tantek: ahh
#
tantek Gargron, yes
#
sandro tantek, that doesn't align with my understanding. (1) there was a polyfill, using the special-domain approach, that worked reasonably well, and (2) it didn't catch on so browsers didn't implement it natively. No magic.
#
dlongley we're seeing essentially the same pattern used and required in both web payments and credentials now -- and we've created polyfills and demo code on the same underlying libraries
#
tantek ajordan: it's a classic failure mode for standards proposals
#
dlongley that you guys (if you wanted) could experiment with if it seems like a good fit for some social features.
#
xmpp-social [ajordan] I would be interested in reading that postmortem if anyone has a link
#
xmpp-social [ajordan] tantek: hah, yes indeed
#
xmpp-social [ajordan] In the meantime I gotta get ready to go to class :-)
#
sandro Sure, web intents failed with users and developers because it wasn't really needed. We need it now, though for web payments, for what Mastodon's doing, etc.
#
tantek I gave the feedback re: webintents very early on when it was proposed and was largely ignored
#
dlongley ajordan: https://paul.kinlan.me/what-happened-to-web-intents/
#
xmpp-social [ajordan] dlongley: thanks!
#
dlongley sure :)
#
sandro So, now we have @Gargron deploying a mastodon-specific solution, instead of having a solution that would work for webpayments, and everyone else, as well.
#
tantek ajordan, dlongley - I mentioned some of the issues around webintents etc in a sidebar on that post http://tantek.com/2011/220/b1/web-actions-a-new-building-block#aside-web-intents-introducers-activities
#
tantek sandro, Gargron's solution is very similar to what we've already spec'd and deployed with webactions
#
tantek so I see the glass half full there
#
sandro (not blaming @Gargron -- I absolutely respect his prioritizing the Mastodon users above the much broader issues)
#
Gargron when i submitted my PR there was a lot of bikeshedding exactly about this sorta thing
#
tantek that is, it appears Gargron independently came to a similar conclusion with prototyping that we did with webactions
#
tantek Gargron - there was SO much bikeshedding about webintents :(
#
Gargron use mastodon in protocol name vs "ostatus" or "social" or something, etc
#
tantek it was a massive waste of time
#
Gargron but it didn't lead anywhere, until there's a standard or draft it's anybody's guess
#
sandro I don't think protocol-handlers vs special-domain was a bikeshed issue at all. It's a prediction about what users will tolerate. As I said, I'll be interested (and surprised) if this works out well with the path you chose.
#
Gargron sandro: ah no i am talking about a different discussion
#
tantek sandro "what users will tolerate" is a pretty low bar and partially why webintents failed
#
tantek the UX model of webintents was horrible if at all defined
#
sandro could be -- I tuned out of some of the discussion
#
Gargron i rejected using a special domain mostly because of the hosting/privacy issues associated with having to run a service like that
#
Gargron e.g. people say "wow cool mastodon doesnt load any 3rd party scripts/cookies"
#
Gargron dont wanna remove that advantage
#
tantek Gargron - good instinct
#
sandro I understand & respect that, absolutely.
#
tantek same with webactions
#
sandro I was thinking w3.org might be able to pull that off.
#
jaywink wouldn't a special domain make it not very decentralized anyway?
#
tantek exactly - shows architectural flaw
#
sandro ie, it's not Mastodon that's the 'central part', it's clearly just a polyfull using w3.org
#
Gargron yes but i can also see from the other way that it would be an optional centralized add-on
#
tantek that's the WordPress / Jetpack approach
#
Gargron anyway, if i may shift the topic a little bit
#
tantek again it compromises and decentralization
#
Gargron does anyone have any brilliant ideas on what we can do with hashtags in activitypub to increase content discoverability - federation-wise
#
sandro jaywink, the special-domain approach is for a polyfill until the browsers see there's uptake and implement it.
#
tantek sandro, we also tried that approach with Persona and that wasn't enough either
#
tantek I'm not convinced of the special-domain approach being effective (what has actually succeeded that way and is still around?)
#
tantek and thus not convinced it's worth pursuing
#
Gargron hey i liked persona
#
sandro Gargron, you mean so folks can search on a hashtag and find its uses even among people / server with whom they have no connection?
#
Gargron i was coding a skype alternative at the time
#
Gargron using webrtc
#
Gargron and wanted to use persona
#
Gargron and then bam, it's discontinued
#
tantek Gargron - lots of us did :/
#
Gargron sandro: yes!
#
jaywink Gargron: in the Diaspora world, we have the relay system that allows any node in the network to publish content there and any node to subscribe - it's kind of an extra thing on top of normal federation. But what I really would love would be some kind of separate index servers which nodes could do lookups against, providing more content to discover. Two ideas :)
#
puckipedia yeah. I'd say e.g. building a small server which stores the IDs of posts with specific hashtags, and servers can POST posts (with authentication), and you can get a few random posts by GETting another endpoint?
#
puckipedia like, you don't even need to store the contents. just the tags
#
Gargron knowing nothing technical about dhh, is this what dhh is for?
#
jaywink well you don't even need authentication as long as the content is public
#
Gargron and i do not mean the rails developer
#
sandro Gargron, I know of two approaches: 3rd party index servers (aka search engines) and flooding out the social graphs. They both have a bunch of issues.
#
puckipedia jaywink: the idea is that you can refuse to have your post indexed
#
tantek yes I believe we have an issue on that
#
tantek puckipedia: but even that does not require auth (e.g. robots.txt)
#
puckipedia jaywink: and I feel like the server should be the last authority. like, it could refuse to publicly index posts from users for reasons
#
sandro Oh yeah I guess a third option is to use a DHT. Not sure why I've discarded that idea before.
#
Gargron oh dht, not dhh. my bad
#
puckipedia would be interesting. sharing ActivityPub activities over DHT
#
jaywink I used to be a bigger fan of the "push content to subscribers" (the relay system which I built for diaspora) but I think the search index server approach is more flexible and requires less pushing - though it would icause much slower stream rendering when looking up content since it would have to be fetched live
#
Gargron i think i found the spec: http://www.bittorrent.org/beps/bep_0005.html
#
Gargron haha, beps
#
Loqi awesome
#
Gargron jaywink: this concerns me because mastodon is still built in such a way that it can only work with locally-stored content
#
Gargron i can't just return somebody else's API response in my APIs, i have to like, process and store it
#
sandro If Mastodon were going to use a DHT for hashtags, it might as well use it for finding users too.
#
jaywink with a search index based solution you could pre-fill users streams with locally from remote indexed content of course
#
tantek search seems like a different enough "application" to be worth building separately than a content store
#
tantek "global" search that is
#
tantek very different from querying a local content store
#
Gargron yes but i mean to use dht or something like that, i would in the end have to download the posts linked by the index before returning them to the user
#
Gargron idk how bad that would be for long-term storage growth
#
jaywink Gargron: what I meant was that you could have a job looking up remote content and pulling it in according to what hashtags your users are following, for example
#
tantek Gargron - hence search indices and caches are built differently than user content stores
#
tantek re: growth etc.
#
tantek also versioning
#
sandro Yeah, the DHT map hashtag => post-URL; and maybe username -> profile-URL. I'm not sure how robust these are to the kinds of abusers that might move in, though. DHTs were robust by the standards of 15 years ago, but not so much today, I suspect.
#
tantek jaywink btw for registration of your site to handle webaction buttons, see: http://indieweb.org/indieconfig#Register_the_web_action_protocol (with example screenshots and video)
#
sandro Whereas SearchEngines can do whatever abuse-prevention they want, and GraphFlooding can be restricted to some diameter, so it basically stays among folks you kind of trust.
#
tantek using web+action: URLs, similar to the web+mastodon: URLs as mentioned
#
jaywink tnx tantek ?
#
tantek jaywink, if you setup indieconfig on your own site, you'll be able to click on and use the like / repost / reply buttons on my posts and have them redirect to your own posting UI on your own site
#
tantek federated UI as it were
#
jaywink but mobile browser support outside of firefox mobile seems limited? https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
#
jaywink and these days mobile browsing has pretty much overtaken desktop browsing, according to some stats at least
dmitriz joined the channel
#
tantek jaywink but for your own site, what do you use?
#
tantek if you have Firefox on Android, you can make it work
#
Gargron ok, i understood pretty much nothing from the DHT document i linked
#
jaywink but if I'm building software for not just myself. I use firefox yes, on both
#
jaywink I guess the app can choose not to render the action buttons if the user is browsing with something that is unlikely to support it protocol handler, otherwise there would be ugly unknown protocol errors for confused users
#
tantek jaywink - so you can at least try it out and see how it would work
#
jaywink I wonder why not all browsers have adopted this. it's hardly new
#
puckipedia Gargron: each node randomly generates an ID, in the same address space as the hashes. and basically, the 'closer' an ID to your node ID, the more routes you store to find a node
#
puckipedia and if you want to find the information about a torrent, you ask the nodes which have an ID closest to the hash of the torrent, and if they know you get the info, if they don't they will tell you the nodes which are even closer to the hash of the torrent
#
puckipedia I think that's about it
#
tantek jaywink - the author of indieconfig - voxpelli - hangs out in #indieweb-dev on Freenode if you want to chat more about it
#
Gargron puckipedia: do you have an idea how to get started with this? would every mastodon server be a DHT node? how does a fresh server know which nodes to connect to?
#
tantek also where that kind of discussion tends to happen
#
tantek has to go for now - nice chatting with you all this (PDT) morning
#
puckipedia Gargron: every server would be a DHT node, and, I guess, a fresh server would have a few trusted nodes (e.g. mastodon.social) which can then be used to bootstrap the DHT
#
tantek Gargron - I'm definitely interested in your opinion on webactions and if it's (e.g. <indie-action> markup and indieconfig polyfill) is something you'd be interested in adding to Mastodon, or adjusting Mastodon's existing web+mastodon support to work as web+action URLs compatible with indieconfig
#
tantek seems like approaches are very close there, and since the indieweb folks have done the work to figure out how to make it work across sites with different backends, seems worth pursuing with Mastodon too
#
tantek (appears to be low incremental work for Mastodon)
#
puckipedia Gargron: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf this is the thing bittorrent dht is based on
#
tantek thanks and see you next time!
#
jaywink wouldn't making every node a DHT node be expensive for everyone? instead of having some external nodes do the index + storage
#
jaywink I realize the information shared would not be the whole object, but still
#
puckipedia jaywink: the idea is that the amount of storage for each node is very small
#
jaywink but to look up hashtags for example, wouldn't I need to fully sync? it's probably I just don't understand :)
#
puckipedia you'd e.g. hash the hashtag (hehehe), and then look up a node which knows posts for that hashtag
#
jaywink ah ok I misunderstood a bit
#
jaywink do I get the posts in last created order? :)
#
Gargron hmm would that actually work tho. it's not just one node that owns the hashtag...
#
puckipedia Gargron: I'd probably consider making the address space way smaller
#
jaywink for example #linux it would be all the nodes in the network
#
puckipedia probably a standard DHT doesn't work for this
#
sandro My understanding/memory is a bit fuzzy, but I think each hashtag ends up mapped to a set of servers. Each of those servers is responsible for answering about which post-URLs are good for those hashtags. By having several of them, you prevent loss when one server goes away (others take its place) and you can detect and recover from a fraction of the nodes being malicious.
#
sandro I just asked a colleague who's a proper expert on DHTs (and is interested in Mastodon) for his thoughts on using Kademlia for this. Hoping he replies soon.
#
jaywink tbh, a simple index server that listens to public content from other "real" nodes and offers a simple search API would go very far. you could have many of these for network redundancy
#
jaywink nextcloud has a nice similar concept for identity discovery, the lookup server which nodes can send identity information to and other nodes can do lookups. like finding users by their twitter handle, for example
#
sandro Yes, absolutely. I'd start with a search-engine interface like that, personally. And I'd get 2-5 independent people to agree to run these servers before rolling it out, so it's clearly decentralized in that way.
#
puckipedia idea: just put all ActivityPub posts into the blockchain
#
sandro Care to calculate how much that would cost?!
#
sandro (hint: a lot)
KevinMarks_ joined the channel
#
Gargron any thoughts on statuses/following/followers numbers? i could use totalItems numbers if i fetch the collections from AP, but they are kinda easily fakeable and would only update when i re-fetch them which i wouldn't want to do on every profile access..?
#
puckipedia though, in mastodon it's also currently really easily fakable
#
Gargron on your *own* server
#
Gargron you cant fake the numbers on somebody else's server easily
#
puckipedia hm. alternatively, make the collections fully readable
#
Gargron well i'm not gonna page through 14,000 items either
#
Gargron so...
#
puckipedia Gargron: alternatively, it's easy enough to make a fake server which fakes 14000 followers
#
puckipedia and I mean, it's more as a side test. like, servers can verify it, or trust it
#
Gargron not "easy enough" imo
#
dmitriz yeah, so basically one either trusts the server's own numbers, or has to set up independent "verification" services
#
Gargron we could display the totalItems number and then "here's the number from our server which is definitely true" though i fear that's just adding confusion to the UX
#
jaywink I don't think you can ever trust another server. Are follower counts that important to protect from faking?
#
Gargron i guess no
#
dmitriz well it depends
#
puckipedia Gargron: "N followers (M from this server)"
#
dmitriz for any sort of mainstream adoption, they are important. (in terms of, many people get book contracts / advertising deals etc, based on their number of followers)
#
puckipedia Gargron: other question. if a server dies/stops working, should the follower count be decremented?
#
dmitriz there should probably be some sort of grace period?
KevinMarks, KevinMarks_ and dmitriz joined the channel
#
cwebber2 Gargron: yeah I think re: totalItems, you can never totally trust it, only the items you know are actually in thre
#
cwebber2 Gargron: unfortunate but I don't know of any way to give just an integer and "prove" it's actually the right number without traversal
#
cwebber2 the best you could do maybe is have some authorities search it and sign off that they checked the number but that seems like a big mess
KevinMarks joined the channel
#
cwebber2 not to mention that the number changes, so the signature would only apply for so long
#
aaronpk thinking about this a bit, it does seem like third-party verification is the only way it can work in a completely distributed system really.
#
cwebber2 aaronpk: yeah otherwise its just way too much traversal
#
cwebber2 every node traversing every collection is just too much
#
aaronpk right now, Brands™ are trusting twitter/instagram/etc to report follower numbers accurately. but they would have no reason to trust a my follower number that I report myself
#
cwebber2 nods
#
aaronpk so it seems like there's a market opportunity for someone to offer verified follower counts
#
cwebber2 Verified(TM)
#
aaronpk and maybe that service does actually traverse the whole graph, cause there'd probably be relatively few services that do that
#
sknebel Would be interesting to have a model where you can prove that you caught a server lying, but that's a lot of effort
#
cwebber2 re: DHT storage for the tags, you still need arbitration of what goes in the hash name of "ribbit" right?
#
cwebber2 you're kinda in zooko's triangle territory there
#
cwebber2 not just kinda
#
cwebber2 definitely
#
cwebber2 https://en.wikipedia.org/wiki/Zooko%27s_triangle
#
cwebber2 "human-meaningful" means you need to give up either decentralized or secure. We don't want to give up decentralized so
#
cwebber2 suddenly thinks that this current era is a bad one to pick a frog-related tag example
#
cwebber2 "flower" then
#
cwebber2 yeah you could put things in a decentralized ledger and actually that would work, and if you don't use bitcoin-style mining it wouldn't be maybe so expensive, and maybe you could have most nodes checkpoint regularly
#
cwebber2 still, I don't know what tech I'd use for that
#
cwebber2 would be highly susceptible to spam tho
#
cwebber2 I guess there's no avoiding that(?)
#
dmitriz maybe the good old google "who links to whom" algorithm might prove useful for weighing?
#
dmitriz (weighing spam nodes etc)
#
cwebber2 dmitriz: yeah
#
cwebber2 well, so a) if you hash every tag, you already have a way to look up each tag, fine
#
cwebber2 b) if you just include the tags that are in your "known network" you're actually probably a-ok
#
cwebber2 I'm going to stop lettering these
#
cwebber2 - you could use the sharedInbox endpoint as a way for some aggregators to snarf up content and index it; that's the "easiest" path towards having global search but it relies on having some larger indexers, and then you do end up in having a Google-like mega-entity problem
#
cwebber2 shrugs
cdchapman and KevinMarks joined the channel
#
cwebber2 puts down regrets for next week's SocialCG meeting
#
cwebber2 looks like I'm gonna be in a dentist's chair... filling popped out
#
cwebber2 probably because I accidentally bit hard into a cherry pit (hard enough to break the cherry pit in half... it hurt)
#
cwebber2 aaronpk can apparently chair tho :)
#
cwebber2 thanks aaronpk!
HDNAJERA, KevinMarks and KevinMarks_ joined the channel
#
puckipedia looks at activitypub commit history. "an excellent unhistorying"
KevinMarks joined the channel
#
cwebber2 puckipedia: heh :)
#
cwebber2 543 commits! lots of work done :)
dmitriz and dmitriz1 joined the channel