#social 2018-06-30
2018-06-30 UTC
fr33domlover2, fr33domlover3, fr33domlover4, cwebber2, fr33domlover and fr33domlover1 joined the channel
fr33domlover3, fr33domlover4 and fr33domlover joined the channel
fr33domlover1 joined the channel
fr33domlover2, fr33domlover3, fr33domlover4, fr33domlover, fr33domlover1, bblfish and xmpp-social joined the channel
# 
jaywink[m] I totally agree, now there are two separate delivery/authority related technologies that have to be implemented when one would have been enough - signatures. They always prove the payload was from who it says it was. Tried hard pushing this during the WG but I guess LDS was too much of a draft - but then now it's required anyway :)
# 
saranix LDS is fairly complex and while it does add the capability of 3rd party transit, there are those that would question whether 3rd party transit is really necessary or even many who believe it's something to be avoided.
# saranix I'm on the side of the fence that is a good thing that AP can be implemented with HTTP sig only
# saranix and FWIW the spec doesn't say you *have* to implement HTTP sig either. If you choose LDsig only without HTTP sig that is spec compliant. It is only bad implementations that insist on both to work.
# jaywink[m] the problem is third-party transit is in the core AP spec. It's not even a SHOULD, it's a MUST.
# saranix where?
# saranix not the same thing
# saranix that can be read to mean only other recipients on the same server
# jaywink[m] well, only if you're aiming for broken discussions ;)
# saranix not true
# saranix broken discussions was again always a bad implementation thing, never a protocol thing
# jaywink[m] "The following section is to mitigate the "ghost replies" problem which occasionally causes problems on federated networks. "
# jaywink[m] It's mentioned in spec - whether or not one thinks it shouldn't be
# saranix it still can be done elsewise
# jaywink[m] sure, you could check from the origin as the third-in-line receiver. but http sigs wont solve this problem, afaict they even make this delivery not possible (though not an expert on http sigs)
# saranix A server need only know of the existence of new replies, it does not need to receive them from anyone in particular. It can also fetch them straight from the canonical source always. 3rd party transit is NOT technically required. It just isn't.
# jaywink[m] the point was we now implement http sigs and LDS - but for what reason do we implement both? (going back to the original question by ajordan)
# saranix and I answered that. Both aren't necessary. So don't. :-P
# jaywink[m] what fun is making a federated platform that doesn't federate with others then? ,)
# jaywink[m] if all the others do, you have to, or your platform doesn't federate
# saranix "be liberal and what you accept, and conservative in what you send"
# jaywink[m] doesn't help if the others don't follow the same rules you do ;)
# saranix you have to ALLOW both... you don't have to (and should REQUIRE) both. Big DIFF
# saranix *shouldn't
# jaywink[m] a protocol will more be defined by implementations not spec
# jaywink[m] and currently implementations are requiring http sigs and lds
# saranix no no no no
# saranix spec doesn't require
# saranix that means those implementations are WRONG
# saranix fix them
# jaywink[m] spec doesn't but implementations do
# saranix exactly
# saranix they are wrong
# saranix fix them
# jaywink[m] that is easy for you to say. hey mastodon, drop your http sigs and lds requirement ok tnx :)
# saranix if they want to say they are spec compliant, they will be able to talk with any other server that implements the minimum spec. If they cannot receive from implementations that follow only the minimum spec, they are lying about being complioant. Plain and simple.
cwebber2 joined the channel
# Gargron jaywink[m]: saranix: aaronpk: LD sigs are not required and indeed only used for forwarding
# Gargron so you can do an implementation entirely without them
# Gargron aaronpk: i heard someone else was also having trouble with the 401 error based on my tutorial. i havent figured out whats wrong yet
# Gargron "why did we implement both http sigs and ld sigs"
# Gargron first off, LD sigs are monstrously complicated to implement due to the canonicalization stuff
# Gargron so having it as a base requirement didn't seem viable
# Gargron http sigs are really simple in comparison and they get the job done: "does this delivery come from the right actor?"
# Gargron and it does make sense that http sigs should not be required if there is an LD signature, it's just due to the order in which they were implemented in mastodon that it's not really possible
cwebber2 and bblfish joined the channel
# dansup Hey up201705417, are you around?
# dansup aaronpk: What language are you using? I found a great http sig/guzzle library
# up201705417 dansup: yes
# dansup aaronpk: Ah I see, this is what pixelfed is using https://github.com/99designs/http-signatures-guzzlehttp
# dansup up201705417: Should we move GNU/Social ActivityPub plugin discussion here?
# up201705417 sure :)
# nightpool[m] aaronpk: i'll try to take a look at that this afternoon, it's probably a stupid logic bug in the ruby code
# dansup up201705417: Sounds good, what do you plan on working on next?
# up201705417 well, per the boards my next task is Actor Inbox: https://git.gnu.io/dansup/ActivityPub/boards
# up201705417 But it might be a good idea to get redis caching and http signatures working first
# up201705417 that's why I was studying about those now
# dansup Did I show you this already? https://redis.io/topics/twitter-clone
# up201705417 oh, nice :)
# dansup up201705417: I wonder if there is an event hook for the search, would be nice to be able to search remote profile/statuses like Mastodon
# up201705417 ahm, isn't that already done by GNU Social? I mean, the moment the instances interact the search already includes the remote instances data, right?
# nightpool[m] only profiles/statuses that are loaded locally
# nightpool[m] mastodon lets you retrieve remote content by urls
# dansup up201705417: https://git.gnu.io/dansup/gnu-social/blob/master/actions/profilecompletion.php#L39
# dansup nightpool[m]: yeah that is pretty cool
# nightpool[m] there are a lot of http signature libraries i know mastodon works with
# nightpool[m] https://github.com/joyent/node-http-signature, for ex
# 
aaronpk am I looking at the wrong spot? Why is the placeholder secret used here? https://github.com/dansup/pixelfed/blob/b9c02e5b6862263bd45747e502fbc76b447aa905/app/Jobs/RemoteFollowPipeline/RemoteFollowPipeline.php#L58
# dansup aaronpk: yeah, and I never finished that. I'm not sure how that landed as a commit already lol
# dansup to verify an incoming payload
# dansup its not committed yet, but I'm pretty close
vasilakisfil joined the channel
# aaronpk Gargron: found the problem! your blog post says "(request-target): POST /inbox\n..." but it should be "(request-target): post /inbox\n..." instead
# nightpool[m] omg
cwebber2 joined the channel
# nightpool[m] aaronpk: they're two different things. Activities have an actor, objects are attributedTo
# nightpool[m] > The attributed entities might not be Actors. For instance, an object might be attributed to the completion of another activity.
# nightpool[m] aaronpk: hmm
# nightpool[m] looks like it's a little ambiguous.
# nightpool[m] When receiving a message, it only cares about the activity
# nightpool[m] but when you look up a post by URL, it doesn't expect to find the enclosing Create, only the Note itself.
# nightpool[m] so it uses attributedTo then
# Gargron aaronpk: thanks for figuring it out and im really sorry about messing it up like that!
# Gargron https://mastodon.social/@Gargron/100296438118964338 credited you
# 
Loqi [Eugen] Hey, earlier version of my blog post about ActivityPub contained a mistake, uppercase POST instead of lowercase post, inside the HTTP signature, which led to it not working in practice. The article is fixed: https://blog.joinmastodon.org/2018/06/how-...