#social 2018-08-14
2018-08-14 UTC
# 
nightpool[m] i don't understand your usecase kaniini. if you're trying to emulate webfinger, why invent another thing to do what webfinger already does?
# saranix nightpool[m]: I think it was the same thing I was saying yesterday. That mastodon can use preferredUsername to acomplish what it wants and does not need to require webfinger.
# nightpool[m] "what mastodon wants" is a unambiguous mapping from "@user@domain" -> activitypub actor
# saranix I defintely fall on the side of breaking-follow-your-nose is bad
# nightpool[m] preferredUsername doesn't accomplish that.
# saranix preferredUsername acomplishes exactly that
# saranix I don't know why you don't see it
# nightpool[m] how do I go from @user@domain to an actor with preferredUsername
# nightpool[m] what is the algorithm.
# donpdonp I believe whats being thrown around is the idea of 'backfilling' a url with an email style id of <preferredUsername>@<host part of url>.
# saranix dead-reckoning is the one exception. A fresh hub with no seeded contacts. This edge case should not rule all other behavior. IOW, if it's the only way, then it's the only way, but requiring it when it's not the only way is bad
# donpdonp it doesnt address starting with an email identifier.
# nightpool[m] i don't think you're understanding what I mean
# nightpool[m] when I say a mapping from "@user@domain" -> activitypub actor
# puckipedia nightpool[m]: what's the use of a unique username. usernames should be able to change
# nightpool[m] puckipedia: almost every service has some amount of uniqueness that people rely on when they're communicating in side-channels, IRL, etc
# nightpool[m] twitter, tumblr and email are obviously unique.
# nightpool[m] discord, battlenet, and other mmo platforms have "tags"
# nightpool[m] facebook gets away with this because if you're using it, it owns your entire social network.
# saranix nightpool[m]: My thing is, if mastodon has enough information to calculate a user@host with preferredusername it already fetched, it *should not* require that it ALSO GET the exact same information from webfinger before working.
# puckipedia nightpool[m]: twitter usernames can change freely
# nightpool[m] puckipedia: .... but they're still unique??
# nightpool[m] i don't understand your question
# puckipedia kinda assumed you were on the changability
# puckipedia I don't like that mastodon keys accounts on username/domain
# nightpool[m] that's a different question.
# puckipedia nightpool[m]: here's the thing. why should the display of a user's account be dependant on a side effect from an unreleated component
# nightpool[m] what?
# puckipedia mastodon figures out it should be e.g. user@example.social instead of user@mastodon.example.social because it's in webfinger
# puckipedia webfinger should not be required to figure this out
# nightpool[m] i'm not sure what you mean
# nightpool[m] user@example.social has no meaning outside of webfinger
# puckipedia then why are we using it all in activitypub
# nightpool[m] people who don't use webfinger, presumably, don't use it
# nightpool[m] people who do, do
# puckipedia why didn't we move to @https://example.social/user when we moved to activitypub
# nightpool[m] who is we here
# puckipedia everyone who moved to activitypub
# puckipedia in general
# puckipedia why didn't we abandon email-style IDs
# nightpool[m] only one software, to my knowledge, moved to activitypub
# nightpool[m] and i've already given the justification for the decision we made at the time.
# nightpool[m] (where "moved" means "used to implement another federated protocol, now implements activitypub")
# nightpool[m] (pleroma has a more complicated history but they were never federated over ostatus)
# saranix point of order, if mastodon requires webfinger to work, and webfinger is not part of the activitypub protocol, then mastodon has not (yet) *moved* to activitypub ;-)
ajordan joined the channel
# nightpool[m] that doesn't make any sense
# donpdonp id say mastodon implements two things, webfinger and activitypub. if it used a different system to translate email to url, the activitypub part would remain unchanged.
# nightpool[m] when mail servers start requiring dmarc, do we say they've STOPPED implementing smtp?
# dansup hey nightpool[m], pleroma can discover a pixelfed profile but mastodon can't. Any idea why?
# dansup curl -H "Accept: application/activity+json" https://pixelfed.social/users/dansup -v
# nightpool[m] I'll take a look when I'm at my computer
# dansup ok thanks!
# puckipedia dansup: wanna bet it's the redirect
# dansup puckipedia: that is fixed
# puckipedia ah
# nightpool[m] are you returning the right content-type header? that seems to be the main error we're running into when debugging federation
# puckipedia dansup: multiple accept values do not work
# puckipedia again
# puckipedia .
# dansup Content-Type: application/activity+json
# puckipedia accept: application/activity+json, text/html
# puckipedia I'm pretty sure I pointed this exact thing out to exactly you before
# dansup MUST present the ActivityStreams object representation in response to application/ld+json; profile="https://www.w3.org/ns/activitystreams", and SHOULD also present the ActivityStreams representation in response to application/activity+json as well.
# puckipedia dansup: multiple content type values is like. an http spec
# puckipedia come on
# dansup puckipedia: I don't understand what you are trying to say
# puckipedia a content-type header can be e.g. application/activity+json, text/html, */*
# puckipedia as in
# puckipedia Content-Type: application/activity+json, text/html, */*
# dansup oh, I thought you were talking about the Accept type
# puckipedia ehm
# puckipedia I WAs
# puckipedia sorry
# puckipedia accept
# puckipedia yes
# puckipedia content type can be one
# puckipedia I ma tired
# dansup I know it can be
# puckipedia but pixelfed isn't accepting it
# dansup oh I see what you are saying now, lol.
# nightpool[m] i think that makes 5/5 "mastodon is mean and not federating correctly!" problems I debug down to bad content negotiation implementations now
# dansup that was an easy fix, in_array() to str_contains()
# puckipedia now I'm gonna give you multiple Accept headers :P
# dansup just wait, its not deployed yet!
# nightpool[m] ..... are you implementing your own content negotiation algorithm now.
# nightpool[m] aren't you using like, php??? is there seriously no library for this?
# dansup yay it works on mastodon now
# dansup puckipedia: I'm sorry I didnt understand what you were saying before
# dansup I think that was the issue with the GS AP plugin, cc up201705417
# nightpool[m] what is the point of having a web framework if you're not going to use it.
# dansup lol what?
# dansup puckipedia: try it now
# dansup nightpool[m]: I could do it a few ways, in the router or middleware but this was the quickest/dirtiest way. Its not even 4 months old yet
# nightpool[m] so, if someone requested something like text/html, application/activity+json; q=0.5, you'd give them the wrong one.
# Gargron i am suddenly curious about how web of trust could work with the fediverse
# saranix nightpool[m]: "when mail servers start requiring dmarc, do we say they've STOPPED implementing smtp?" 1) this is probably why thy never will require it, 2) dmarc is a standard on too of existing email infrastructure specifically on top of smtp. webfinger was not built specifically on top of activitypub. it is a totally different standard
# dansup nightpool[m]: oh, I need to use prefers() rather than accepts()
# nightpool[m] Gargron: did you see my reply to j?
# nightpool[m] i'm guessing we could implement a really basic web-of-trust thing completely with local information and fix 90% of the problem
# nightpool[m] since spammers aren't exactly setting up their own mastodon servers lol
# Gargron yes, but it reminded me of how everybody wants some form of verified accounts
# nightpool[m] eh
# saranix Gargron: good you're here. Maybe you can settle this finally. I say it's a bug that if you try to add a non-webfinger contact (i.e. @https://foo.example) and mastodon then refuses to lookup that contact because it doesn't *also have* a webfinger
# Gargron its not a bug, i designed it that way
# saranix it's designed to require something it doesn't need?
# Gargron you could put it that way
# Gargron if you cant mention it using plaintext in mastodon, there's no point in that account entering the database
# saranix activitypub spec does not have webfinger, requiring it means that mastodon can't talk activitypub
# saranix gargon: but pleroma does, it uses preferredusername
# saranix Gargron: it is the same information. simply refusing to accept it because it does not come from webfinger is just wrong
# donpdonp Gargron: re: verified accounts, in ssb "you are your ed25519 key". if mastodon allowed for private key upload, that might be a way forward.
# Gargron private key upload doesnt sound safe
# Gargron but i guess requiring something else would be too much for normal people
# nightpool[m] "normal people" don't have private keys
# Gargron true too. it wouldnt be much use unless you could also prove ownership of the key by posting on twitter or somewhere else, which requires gnupg knowledge
# Gargron simplest example, real gargron vs impersonators
# Gargron more practically, let's say "John Scalzi"
# Gargron i mean, its a choice
# nightpool[m] yeah, verification is inherently a "human" thing. i could make a keybase account that says my name is Eugen Rochko and convince my friends to sign it, but it wouldn't mean anything in terms of "verification"
# saranix Gargron: "if you cant mention it using plaintext in mastodon, there's no point in that account entering the database". ok fine but you can. preferredUsername is the same information. if mastodon already has it, it should stop looking for it another place and then complaining when it can't find it.
# dansup request()->wantsJson() was the key, no dealing with headers :)
# nightpool[m] wow
# nightpool[m] hearing php try to talk about libraries is just like a whole other world.
# donpdonp php has come a long way.
# nightpool[m] in rails, all we do is register the two mime types, and then we immediately have response parsing built in
# dansup nightpool[m]: its not a contest :)
# nightpool[m] sure, but that's the opposite of what you want
# nightpool[m] the controller should be able to say "here's the list of content types I can respond with", and the framework should figure out which is the best content-type for that request.
# nightpool[m] and call the associated functions/lambdas/closures or w/e
# dansup you can do that too, or call middleware from the route
# Gargron back on the WOT thing. keybase is popular as a way to verify that you on one site is you on another
# Gargron but keybase still doesnt support mastodon or AP or anything, and even if it did that info would be stashed away
# nightpool[m] popular is maybe stretching it
# Gargron whats more popular is the twitter verified checkmark, which is controversial and yet desired by vulnerable people as a means of preventing impersonation attacks
# dansup Yeah, thats true
# Gargron i think this should not be a celebrity status thing, but really just a way to prevent impersonations.
# Gargron so after spending so much time explaining why i am interested in it, can anyone explain if WOT is a possible approach for it and how it would work
# nightpool[m] cwebber2: ping
# nightpool[m] my gut says "yes" because most people are entering the network with some form of personal connection to someone they trust
# Gargron the backup solution is if you let servers vote... assuming that an admin/mod would check the account independently, then vote for its integrity (local or remote no matter), and then on the origin server it would display which servers have verified the account
# Gargron oh wait nevermind the origin server could just fake that
# Gargron unless the origin server would forward those votes so receivers would be able to verify those votes came from those servers.
# Gargron growing complicated.
# dansup Gargron: Why not just do what keybase does, generate a proof to upload to twitter or github and then that acts as validation? Keybase not required
# dansup you already have the private keys to generate one
# dansup 3rd parties could verify it too
# Gargron hmm
# Gargron for 3rd parties to validate it, the validation snippet would have to be public, and those identities too
# Gargron so it would have to be encoded in AP somehow
# Gargron would we have to add special handling for twitter? keybase seems to; and they periodically re-check, i'm not sure if that's truly necessary, but if we didn't add special handling the tweet with the snippet would fall off the profile page
# Gargron of course we already have *a* form of verification: each link in the profile fields is marked up with rel="me" so if the page linked contains a link back also with rel="me", that's a verification. of course, nobody uses that, and you couldn't make it work with twitter or fb anyway, only custom websites.
# Gargron i am tempted to return that whole idea to "unsolveable"
# dansup yeah, it would require a lot of work and it might not be used enough to warrant that
# dansup Gargron: btw, pixelfed will be supporting federating pretty soon. https://mastodon.social/web/accounts/418582
# dansup federation*
# Gargron cool cool
# kaniini anyway my conclusion is that i don't want pleroma to be as deeply involved with webfinger as mastodon is
# kaniini so the feature isn't that important to me
# saranix kaniini: from my point of view pleroma is activitypub compliant and mastodon isn't. They both use webfinger but pleroma doesn't require it but mastodon does
# kaniini i would hope that pleroma is activitypub compliant in some way, pleroma's AS2 internal representation was based on an early draft of AP
# dansup saranix: how else does pleroma handle discovery? meta tags?
# kaniini pleroma can do discovery a few different ways
# kaniini like i said earlier
# kaniini it is possible if you know what you're doing
# kaniini to build pleroma without webfinger at all
# saranix kaniini: well technically there is one non-compliance but it's not that big of a deal. It requires the preferredUsername property even though the spec says it's a "SHOULD".
# kaniini saranix pleroma does not require preferredUsername
# kaniini it will show the URI of the user instead of building a user@domain
# saranix kaniini: with the live server I was testing with it would not accept the actor until I added a preferredIsername property
# kaniini that's the default configuration yes
# kaniini the core itself does not care though
# dansup webfinger isnt that bad, nodeinfo uses .well-known too
# dansup it does require an additional http req, thats about it
# kaniini dansup i'm not against webfinger, i just do not think the implementation should be locked into it
# dansup whose implementation?
# kaniini any
# kaniini if we were against webfinger, pleroma wouldn't have it
# kaniini but pleroma keeps webfinger solely in the discovery box
# kaniini if you give an AP actor URI, that works too
# kaniini anyway
# kaniini i solve verified accounts for you
# kaniini people send me money
# kaniini i say they are ok
# kaniini win win
# kaniini ;)
# kaniini no, this isn't the CA debacle all over again
# kaniini never !
# kaniini saranix anyway
# kaniini saranix the internal core functions fine without preferredUsername. if you know what you're doing, those checks can be bypassed
# kaniini saranix the problem is, in practice, the APIs we provide get upset when there is no preferredUsername
# saranix requiring a SHOULD property on an object already being transferred isn't that big of a transgression. Requiring a whole seperate request from a completely different and in some ways competing protocol is just all kinds of rude.
# kaniini saranix pleroma core does not require preferredUsername: https://pleroma.site/relay
# dansup yeah
# dansup but
# dansup you have to consider revocation, so you have to periodically validate that trust
# dansup hello!
# dansup cwebber2: https://mastodon.social/@pixelfed/100546035248288207 !
# nightpool[m] some wot thoughts in the backscroll for you cwebber
# nightpool[m] and also "there is no ethical consumption under webfinger" vol. 200
# 
cwebber2 first of all I wrote a good chunk of this already in an (unfinished) paper for RWoT https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/making-dids-invisible-with-petnames.md
# saranix the problem isn't the consumption of webfinger, it's the requiring of it. Bottom line is, it is not in the activitypub spec. I don't think it was ever even being considered for inclusion but if it was, we all voted against it and approved a spec without it. So for mastodon to require it is a big *expletive* to all of us who worked on the protocol and approved what got approved
# saranix cwebber2: what you described is basically how the WoT I've been developing for about 7 years works (based on massive research and just about every rwot page ever published)
# saranix so sad
# saranix you got all this in the form of an article/deck? This feels very much like an "idiot's guide" that would be great to share
# saranix ones which also reflect existing realworld paradigms instead of inventing new ones "on the interwebs"
# saranix even non-malicious dns names can be confusing. great.tech, great.technology, greattech.com, greattechco.com, greattech.llc, etc.
# saranix cwebber2: same type different property. another property would be the triple I trust xxx to do yyy. Or I trust that when xxx talks on topic yyy it is truthful
# saranix s/triple/quad since I = 1
# saranix still, just encoding real world actual social trust networks into bits and chars
# saranix gnite
xmpp-social, vasilakisfil and Chocobozzz joined the channel
cwebber2 joined the channel
dlongley joined the channel
# up201705417 dansup, nightpool: Yeah, GS had the same Accept Header issue and it was solved by using this lib: https://git.gnu.io/dansup/ActivityPub/blob/dev/utils/AcceptHeader.php
# up201705417 fixed in this commit: https://git.gnu.io/dansup/ActivityPub/commit/f25d8278b1635f14e47bde9a1573527c7f48d8db :)
# up201705417 puckipedia: well.. GS supports email like IDs both because it is easier to type and due to OStatus compatibility
# up201705417 but we are supporting ActivityPub like identifiers with no issues as well :)
# up201705417 in our case we have a little special route to make everything easier on email like ideas, a somewhat innocent hack xD
# up201705417 and that brings no problems because of ids consistency ^^
# up201705417 we are using GS webfinger plugin so I can't really explain the internals of it, but the implementation was kinda easy on AP Plugin side :)
cdchapman, cwebber2 and ajordan joined the channel
# puckipedia .. eww, mastodon does some nasty things if a post that is replied is removed
# puckipedia i mean, not your fault
# puckipedia but
# puckipedia bad behavior on Mastodon's side
# nightpool[m] what do you mean "that is replied"?
# puckipedia nightpool[m]: inReplyTo is nulled if the post that it originally pointed to is removed
# nightpool[m] yeah?
# puckipedia so now there's no indication that the post was ever a reply
# saranix lights a gas lantern
# nightpool[m] because it's not a reply anymore
# puckipedia it's still a reply
# nightpool[m] maybe, but it's certainly no longer inReplyTo anything
# saranix s/could/supposed to
# nightpool[m] tombstone is a may
# nightpool[m] we chose not to implement it for privacy/security reasons
# nightpool[m] ideally, if you delete a post on mastodon, noone later should be able to tell that it existed
# JasonRobinson[m] are there really replies in microblogging? it's all just statuses isn't it? sure you can link them, but in the end they're individual statuses
# saranix JasonRobinson[m]: you make microblogging sound like flatulence... oh wait
# 
aaronpk these look like replies to me https://aaronparecki.com/replies
# saranix so that's why they call them toots I guess
# puckipedia nightpool[m]: just link it to the deleted post and let the other servers figure it out
timbl joined the channel