#social 2017-04-21

2017-04-21 UTC
tantek and KevinMarks_ joined the channel
#
tantek KevinMarks that's amazing
#
Loqi tantek: ajordan left you a message 9 hours, 31 minutes ago: yeah, I was thinking about this last night and I've changed my mind to be tentatively in favor of at least sending Webmentions, subject to Evan's approval. it's just so simple
#
Loqi tantek: ajordan left you a message 9 hours, 30 minutes ago: not sure about receiving since then we get into hairy questions about how to present that to both API clients and users, but
#
tantek \o/ awesome ajordan! glad to hear it
#
tantek receiving webmention is a bit more work, but for any system that already has a notion of receiving federated content from outside servers/networks, it should map fairly directly
KevinMarks, KevinMarks_ and tantek joined the channel
#
tantek Kevinmarks, all these different Mastodon instances seem to require email for login - I wonder if it would be possible to patch Mastodon to use IndieAuth for sign-up instead, and not require yet another user/pass
#
tantek and then the next trick would be to somehow have that Mastodon instance use your indieweb URL as identity instead of it's own @something@server
KevinMarks and timbl joined the channel
#
aaronpk The real trick is just letting Mastodon users subscribe to your URL directly
#
aaronpk I made some progress on that today but hit a snag at the last step
#
tantek I feel like the key there is making Mastodon work without Webfinger
#
tantek Statusnet worked without Webfinger (e.g. people were able to subscribe to tantek.com)
#
tantek so at least there's some prior work there that hopefully made it into GnuSocial and could be similarly implemented in Mastodon
#
aaronpk Well the initial response from Mastodon was that they didn't want to support "non-interactive" feeds, so it basically requires Salmon so that it has a way to send things back to you. Of course webmention does this too so it should be possible to accomplish interactive feeds that way too
#
tantek not wanting to follow "non-interactive" feeds seems a bit dogmatic rather than practical. that's confusing
#
tantek similarly Statusnet had a policy of not bothering to support non-PuSHed feeds but that actually made more sense, since they wanted to focus on "realtime" and not have to poll
#
tantek this also belies incentive among competitive options, that is, I would assume people would shift to the reading UI that allows them to follow more things, across more networks etc.
#
tantek also this: "the initial response from Mastodon was that **they** didn't want to support 'non-interactive' feeds" is a prime example of the problem of monoculture
#
aaronpk It makes sense to some extent tho. To follow a non interactive feed it becomes a UI challenge. you'd have to have some sort of indicator that you can't reply to a particular post in the feed. Then people would ask why not?
#
aaronpk I can understand not wanting to deal with those challenges
#
aaronpk But yeah this is a classic monoculture problem
#
tantek "some sort of indicator that you can't reply to a particular post in the feed", um like don't display the repost, reply, or like buttons/webactions ?
#
aaronpk That would work. And then handling questions when people are confused about why there is no reply button
#
tantek Actually this should be a post feature, and some silos and projects already implemented this. [x] turn off comments for this post
#
tantek E.g. WordPress has that (open source), and Instagram lets you do that per post as well
#
aaronpk I'm just saying I think it's an understandable decision, even if I wouldn't make the same call on it
#
tantek And to be fair, in a federated context, you can still post a reply/repost/like on your own account, the only difference is that it may not show up on the thing you're responding to, which may be true / likely in a federeated context anyway!
#
tantek E.g. even in Mastodon <-> Mastodon instances, you could have one way blocking / banning, so a reply on one instance would not show up on the other instance
#
tantek so I take it back, there is no good reason
#
tantek rather there is no reason to treat "non-interactive feeds" any differently than following a user on another Mastodon instance that is not accepting responses from the current instance
#
tantek (I'm assuming such one-way follows are possible in Mastodon <-> Mastodon interactions)
#
tantek lastly, that 'non-interactive' aspect could just be that Mastodon doesn't support sending Webmentions (yet). no reason not to support the follow now, and implement (and send!) webmentions later, after the fact
#
tantek especially since, as ajordan pointed out, sending webmentions is fairly trivial to implement!
#
aaronpk But you have to think about it from the perspective of someone building a product for other people. If you want to provide a simple and consistent interface, you're going to have to make decisions like only showing posts that can be replied to.
#
aaronpk Its a very different perspective than someone building software that only they will use, where they are aware of the whole picture and want to be able to post replies even if the reply won't reach the destination
#
tantek Instgram has to provide a simple and consistent interface, and they were ok with some posts allowing comments, and others not
#
tantek and like I said, you can't even guarantee you can reply to posts on other Mastodon instances, because of the ability for Mastodon instances to one-way block all responses from other specific Mastodon instances
#
tantek so Mastodon doesn't even do "only showing posts that can be replied to" right now
#
aaronpk Btw today I discovered that Mastodon notifies the other person if you block them
#
tantek whoa wat
#
aaronpk Via Salmon anyway
#
aaronpk not sure if the UI does anything with the info
tantek, KevinMarks, KevinMarks_, dmitriz and timbl joined the channel
#
@erlenzeisig Activity Streams 2.0 has been proposed: https://www.w3.org/TR/activitystreams-core/ (twitter.com/_/status/855423166574886913)
KevinMarks_ and KevinMarks joined the channel
#
ajordan aaronpk: :/
#
ajordan that seems like a huge privacy concern
#
aaronpk yeah....
#
ajordan although I _sort of_ see the reasoning that led to that
#
aaronpk muting does not notify the other person, which i would expect
#
ajordan because if you aren't able to comment on somoene's post, how does that look in a federated context? when you distribute the activity do you get an error? how do you propogate that back to the UI and the API? it's tricky to get right
#
aaronpk i'm on the fence about whether that notification should be sent for block tho
#
aaronpk the blocked person will know they're blocked if they try to visit the user's profile (how twitter does it)
#
ajordan much easier technically speaking to just notify about blocks so the server with the blocked user doesn't even try distribution
#
ajordan certainly though I agre it's unideal
#
ajordan aaronpk: right
#
aaronpk so in a federated context, proactively notifying about the block makes sense becasuse the blocked user's software can then just immeditaely stop showing things
#
aaronpk but it requires cooperation on the part of the blocked user's software, which is... weird
#
aaronpk frankly the subtleties of what blocking means and how people use it indicate that it should not be part of a spec right now
#
aaronpk at least not part of a federating spec
#
ajordan yeah
#
ajordan I don't remember what AP says about blocking
#
ajordan but there's definitely language in there about it
#
ajordan > The server SHOULD prevent the blocked user from interacting with any object posted by the actor.
#
ajordan > Servers SHOULD NOT deliver Block Activities to their object.
#
ajordan hm
#
aaronpk that sounds like it's intended for the client-server part of the spec, not the server-server
#
aaronpk which makes sense
#
aaronpk a lot of activitypub gets the client-server and server-server bits mixed up in the spec. that was one of the reasons i was in favor of splitting it into two specs.
#
ajordan yeah it's in the C2S part
#
aaronpk ah yeah, there isn't a Block activity in S2S
#
ajordan yep
#
aaronpk yeah it's great to have that for a client-server spec
#
ajordan yeah it makes sense in that context
#
ajordan easier
#
cwebber aaronpk: it's pretty clearly separated now in the C2S and S2S for things like that
#
cwebber it wasn't a year ago though
#
cwebber a lot of that is thanks to rhiaro's help
#
aaronpk Yeah that helps a lot now. I think the language there is still written as if they're combined so it confused me at first until I noticed the section headers
tantek joined the channel
#
ajordan aaronpk: we could try to spruce that up. it's just editorial
dmitriz joined the channel
#
Loqi Cwebber2 made 1 edit to [[Socialwg/ActivityPub network]] https://www.w3.org/wiki/index.php?diff=102670&oldid=102383
#
Loqi Tantekelik made 1 edit to [[Socialwg/Social API/Requirements]] https://www.w3.org/wiki/index.php?diff=102671&oldid=85701
#
Loqi Kmarks2 made 3 edits to [[Socialwg/AccountDiscovery]] https://www.w3.org/wiki/index.php?diff=102759&oldid=0
#
Loqi Cwebber2 made 1 edit to [[Socialwg/ActivityPub network]] https://www.w3.org/wiki/index.php?diff=102796&oldid=102670
timbl joined the channel