#social 2018-09-02
2018-09-02 UTC
KevinMarks_ joined the channel
# 
saranix that's in ap spec
KevinMarks joined the channel
# saranix <heluecht[m]> Do you know some outboxes besides Pleroma, Mastodon and Hubzilla? -- anyone know of any others?
# saranix not even just outboxes
# saranix any impl I'm looking for
# saranix that I can possibly test with
# saranix also, anyone else get federation working with mastodon/hubzilla? were there any tricks? My pleroma worked right out the box but the other 2 are still not working even after massive accomodations
# dansup saranix: https://pixelfed.social/users/dansup/outbox
# dansup working on federation right now :)
# heluecht[m] dansup: What is the reason you are using fields like "inReplyToAtomUri"?
# dansup legacy ostatus support
# dansup still working on removing OStatus
# heluecht[m] But it does contain the same value as "inReplyTo". Or is there some usecase where this isn't the case?
xmpp-social and raucao joined the channel
# heluecht[m] What about changing nicknames on existing accounts? Is this supported or mustn't "preferredUsername" never change?
timbl joined the channel
# vasilakisfil heluecht[m] looking the spec, it says that `This specification registers the "webfinger" well-known URI in the "Well-Known URIs" registry as defined by RFC 5785`. Doesn't this mean that we won't have an unknown url path but instead it will be like http://domain.tld/.well-known/webfinger ?
# vasilakisfil or is this just a convention ? (having the webfinger under well-known url)
# vasilakisfil to me it feels like webfinger is something like Mark's json home (https://www.ietf.org/archive/id/draft-nottingham-json-home-06.txt) for APIs. A starting point for a domain. I might be wrong though but that's what I feel is useful for.
# heluecht[m] The path http://domain.tld/.well-known/webfinger is fixed. In the past you also had to parse http://domain.tld/.well-known/host-meta to find the webfinger url. But at some point the webfinger path was fixed.
# heluecht[m] This "host-meta" would be fine to find out the path for the shared inbox.
# vasilakisfil ah didn't know about https://tools.ietf.org/html/rfc6415 (host-meta)
# heluecht[m] I don't know the RFCs very much. I mostly learn by reading existing code and analyzing existing protocol content.
# heluecht[m] I like to learn by reverse engineering.
# vasilakisfil rfcs are very explanatory with enrmous details if you know the domain, but not good at all to intoduce in something
# heluecht[m] And I do have massive problems in understand formal stuff - especially when it isn't written in German.
# vasilakisfil I see
# vasilakisfil I am looking to build a social Voip protocol using web standards and webrtc
# vasilakisfil webrtc allows you to do cross-domain calls (from foo.com to bar.com) so I think there is a nice opportunity to get rid off the big players that use our data to make money.
# heluecht[m] Nextcloud is doing something like this as well.
# heluecht[m] And Nextcloud is planning to support AP as well.
# JasonRobinson[m] They actually already use AP between Nextcloud servers
# JasonRobinson[m] Just not in a way that is compatible with the other implementations
# vasilakisfil ah let me check it
# vasilakisfil I think they use AP for the chat part, not the voip part
# vasilakisfil I think the chat part is much more complex, and you get many options on how to design your solution. I am interested only on the voip/calls part.
# vasilakisfil also it doesn't seem to have optimized it for cross-domain functionality, in the philosophie of indieweb basically (everyone has her own domain that he/she trusts)
# vasilakisfil yeah I can't find anything regarding how cross-domain calls should take place
# vasilakisfil because ideally I should be able to build my own app that can work with my friend's nextcloud talk app. But in order to achieve this, the underlying protocols must be based in web standards (and if not should be definitely documented somewhere).
# heluecht[m] I think that Nextcloud is committed to open stuff - that's why they forked from Owncloud. So we should see how this evolves.
# heluecht[m] I'm currently analyzing AP data (I'm scanning all outboxes in my reach). I have q question: Is there any need as a receiver of a post to store "to", "cc" or "bcc"?
# JasonRobinson[m] At least for non-public you'll need to store them to see if local users can access the content.
# JasonRobinson[m] Can't think of anything else really
KevinMarks_ and KevinMarks joined the channel
# saranix there any need as a receiver of a post to store "to", "cc" or "bcc"? ->> for activitypub (activity+json) requests no, if you've already used it for delivery you can discard because no other servers will come looking for it at your server, however, for web interface with non-publicposts, you will want to check against for authorization while formulating the web page
# saranix only that 1 use case that I can think of
KevinMarks joined the channel