#social 2018-08-24
2018-08-24 UTC
timbl joined the channel
# 
fiatjaf what about the webfinger stuff, should I implement that?
# nightpool[m] I mean, it's up to you
# fiatjaf what are the other things that are not in the spec but I must implement anyway?
# nightpool[m] it depends on what's you're building and why
# fiatjaf what purpose do these things solve?
# fiatjaf it's confusing
# fiatjaf I'm trying to understand first
# nightpool[m] trying to understand what, specifically?
# nightpool[m] There's nothing that you *must* implement. there are just reasons to implement different things.
# fiatjaf ok, I get that
# nightpool[m] so it's hard for me to give you a more direct answer without knowing your usecase
# dansup fiatjaf: What are you building?
# fiatjaf I don't know yet, I have many ideas and I'm trying to understand what is feasible
# fiatjaf for example, a forum -- or a place where multiple forums could be created
# fiatjaf and activitypub actors could comment
# fiatjaf that's something I would like to create
# fiatjaf I'm not sure if it is possible
# nightpool[m] well, anything is possible. we have computers :P
# fiatjaf you asked for a specific use case
# nightpool[m] yeah and that's a good one!
# fiatjaf now you're trolling me
# nightpool[m] no, I was just pointing out that your usage of "possible" was confusing me
# nightpool[m] sorry if that came off as overly flippant
# fiatjaf :P
# fiatjaf ok, so it's feasible
# fiatjaf in that case, why would I want webfinger?
# nightpool[m] so when you mean "possible" do you mean "is it theoretically possible to do this with ActivityPub" or "is it a good idea" or "is it possible to do this an have a meaningful level of compatibility with the network that already exists?"
# nightpool[m] those all have different answers.
# fiatjaf I mean theoretically possible
# nightpool[m] okay I'm still confused then :(
# nightpool[m] why wouldn't it be possible?
# fiatjaf because activitypub is limited
# nightpool[m] sure, but it's extensible
# fiatjaf ok, I mean "theoretically possible to do this with ActivityPub"
# fiatjaf but as a side note I want to know if this would have a meaningful level of compatibility with the network that already exists
# dansup fiatjaf: someone is building a type of forum like reddit. https://mastodon.social/@prismo/100164341356492119
# 
Loqi [Prismo △] #activitypub based Link Aggregation app is coming really soon! 🤠 https://files.mastodon.social/media_attachments/files/004/376/046/original/751727c9ce7ec570.png
# nightpool[m] so I guess my first cut answer would be "yes, it's probably pretty easy to represent this with ActivityPub semantics"
# dansup development seems stalled though
# nightpool[m] depending on the specifics of how you want the federation to work you might find it more or less complicated
# nightpool[m] but it's definitely possible
# fiatjaf when you say federation you mean federation between multiple servers of my-forum-software or between my-forum-software and mastodon?
# nightpool[m] the former
# nightpool[m] federating between forum software and a microblogging software..... that's probably a trickier proposition
# nightpool[m] what kind of ux were you imagining, on the mastodon side?
# fiatjaf I was imagining people sending comments through normal "toots" targeted at the forum-topic@forum.software or something like that, but nobody wants that ux, right?
# fiatjaf ok, let's discard that idea
# fiatjaf so, what is the purpose of webfinger, in this case?
# fiatjaf also, everybody is using http signatures, but if my-forum-software is only talking to other my-forum-software instances, then I can implement the federation as I please and don't use http signatures at all?
# nightpool[m] webfinger allows you to have a plain text mapping between human-authorable mentions and Actor URIs
# nightpool[m] without any extra markup or anything
# fiatjaf who uses webfinger?
# nightpool[m] mastodon, gnu social, pleroma (ish? they keep saying they don't require it but they definitely use it for authoring mentions)
# nightpool[m] the microblogging services, mainly, because they inherit the twitter "plain text is better then rich text" design
# fiatjaf when you mention @someone@some.where on a mastodon message the server queries some.where/.well-known/webfinger for 'someone' and gets back an url like some.where/user/someone
# nightpool[m] yea
# nightpool[m] twitters focus on plain text started because of SMS but stayed around because it made for easily understood system
# fiatjaf then it queries some.where/user/someone to get an inbox and outbox url
# nightpool[m] well to get the actor representation more generally
# nightpool[m] but the inbox is the most important part, yes
# fiatjaf and sends a CREATE action to the inbox url
# dansup I should really finish the ActivityPub Guide
# fiatjaf dansup, that would be great :P
# nightpool[m] that's basically the long and short of it, yes
# fiatjaf now a silly question:
# fiatjaf do all these implementations store their data as activitystreams objects?
# fiatjaf or do they store them in custom formats and build the activitystreams objects on request time?
# nightpool[m] depends
# fiatjaf it doesn't really matter?
# dansup no it doesnt matter
# dansup fiatjaf: what programming language are you using?
# nightpool[m] pleroma theoretically does, although in practice they have to do a lot of reformatting before federating them
# nightpool[m] mastodon doesn't store ActivityStreams objects at all
# fiatjaf dansup, I was trying to use go, but go-fed compilation uses much more memory than I have -- also, I don't understand how it works
# fiatjaf I guess I'll build my thing from scratch, that's why I'm worried about public keys and http signatures
# fiatjaf :P
# dansup I forked their PHP library for pixelfed :D
# dansup tesla uses their ruby version of that package
# fiatjaf do I have to create a public key for each user/actor on a server?
# nightpool[m] up to you
# fiatjaf what is the other option?
# dansup fiatjaf: for S2S yes
# fiatjaf what is S2S?
# nightpool[m] there's nothing that specifies uniqueness dansup
# dansup Server to Server federation, very few implementations support Client to Server
# dansup nightpool[m]: yeah true
# dansup nightpool[m]: does mastodon use a single key for each instance?
# fiatjaf you mean I could just have one keypair
# fiatjaf makes more sense
# nightpool[m] dansup: not currently but there was a proposal to do it a while back
# dansup yeah I never considered that. I generate one during user registration. https://github.com/pixelfed/pixelfed/blob/dev/app/Observer/UserObserver.php#L23-L34
# nightpool[m] the idea though is that if users have unique keys, they can back them up in case the server they're on goes down
# dansup ah, yes that is cool. Is that part of the data-export?
# fiatjaf what is the idea behind client-to-server protocol?
# nightpool[m] tbd
# dansup If users can export their private key, couldn't they forge sigs?
# fiatjaf to have multiple client apps that are able to talk to multiple server apps?
# nightpool[m] dansup: let's take this offline
# nightpool[m] fiatjaf: yeah, exactly
# nightpool[m] having intercompatible client apps opens up a huge amount of possibilities for variation on user experience
# nightpool[m] just like email has a lot of different clients you can use for the same servers
# fiatjaf but I fail to see a really compelling use case
# nightpool[m] so do most implementors, currently
# fiatjaf in my forum software case, for example, imagine someone has an account on pixelfed.place and it supports C2S
# nightpool[m] but theoretically it would allow you to swap out the server completely, or migrate from server to server, without disrupting the user experience
# dansup OAuth/APIs serve us better than C2S. The server handles a lot of things that a client would have too, and might not be possible.
# nightpool[m] basically it puts the "application specific" logic into the client side, instead of the server.
# dansup us == pixelfed
# nightpool[m] so you'd have a "pixelfed" client that saw everything as a Instagram like stream of images, and discarded the stuff it didn't care about
# nightpool[m] but you could use a "forum" client with the exact same user account on the exact same server, and see a "forum-like" view of the world
# dansup I dont think any app developers want to re-implement AP support for a C2S app when they are already familiar with the mastodon api
# fiatjaf that's only if they're implementing mastodon clones
# fiatjaf I like the idea of C2S very much
# dansup not really, pixelfed uses same api structure too
# nightpool[m] ehhhh
# nightpool[m] it's a complicated discussion
# fiatjaf but how does C2S handles new types of objects and activities?
# nightpool[m] the same as ActivityPub generally does
# fiatjaf implementing C2S means the server reacts automatically to client requests?
# fiatjaf I mean
# fiatjaf imagine whatever.place implements C2S. I use a forum.app client to talk to my own inbox at whatever.place
# fiatjaf because forum.app is a client that knows the type "Thread" I can create a thread on whatever.place
# dansup fiatjaf: yes, and keep in mind almost no implementations support C2S yet. https://activitypub.rocks/implementation-report/
# fiatjaf whatever.place is a microblogging server that doesn't understand threads at all, but it will relay my Thread object to forum.place anyway
# dansup Its not a bad idea, its just not suitable for every implementation.
# nightpool[m] yes, ideally, if whatever.place is a good c2s server, it doesn't matter
# nightpool[m] it'll pass it through and do whatever delivery it needs to do based off of the standard audience and whatever, which should work just fine.
# fiatjaf but for that to work whatever.place would have to store the activitystreams in full
# nightpool[m] yes
# fiatjaf cool
# fiatjaf thank you very much for your patience
# nightpool[m] no worries.
# nightpool[m] kroeg (c#) is a full c2s/s2s server and client
# nightpool[m] it's also being rewritten in rust, and I think at least the server federation is working.
xmpp-social, vasilakisfil and timbl joined the channel
# saranix "http signatures avoid a "round-trip" problem, where sending a message requires a subsequent GET request to authenticate the activity" -- there is still a round-trip when you have to fetch a never-before-seen actor to get their key, depending on how they have their key, possibly even multiple requests ...
# saranix ... it should also be noted that http-signatures are required if you want to do non-public statuses. because even with a get, that GET can't be authorized for access without a http-signature.
# saranix s/statuses/'things'
# nightpool[m] yes although there are less complicated solutions to that, like ephemeral Bearer tokens
# nightpool[m] but like dansup said, any time you're convincing a foreign server to make a request, that's ddos vector
# nightpool[m] *that's a
# saranix nightpool[m]: ah yes that's an interesting workaround... I'll have to try that in one of my toy implementations one day
# nightpool[m] ..... once per actor?
# nightpool[m] ah, but i guess they're still a dos vulnerability, you mean.
# nightpool[m] hmm. yeah. good to think about
# nightpool[m] well, dansup brought it up.
# nightpool[m] we don't use http signatures to avoid a dos vector, we use them for performance.
# fiatjaf how should I go if I want to use types not defined by activitystreams?
# fiatjaf or should I try to use the types already existing
# fiatjaf slightly changing their meaning in my implementation
# nightpool[m] fiatjaf: json-ld properties are just URIs
# nightpool[m] so something like "Note" maps to `https://w3.org/ns/activitystreams#Note`
# nightpool[m] through the definition at `https://www.w3.org/ns/activitystreams.jsonld`
# nightpool[m] which is referenced by the @context at the beginning of the document
# fiatjaf what you're saying is that I want a new type I just want to define it and make it available on some uri?
# nightpool[m] making it available isn't required
# nightpool[m] it just needs to be defined as a unique uri (so ideally one you have control over)
# nightpool[m] now, for individual types, i think it depends on what things you want to define. "Note" is probably fine to use for a forum post
# nightpool[m] for example
# nightpool[m] it mostly depends on what you're trying to do with it. Most times there's no reason to define new types, you just want to add some properties to existing types. Other times, you might want to use something like Example 17 here: https://www.w3.org/TR/activitystreams-core/#activities to define multiple types for an object
# 
csarven fiatjaf: Good question! To add to nightpool[m] 's .. You should indeed try to reuse existing types if they sufficiently help you to describe what you want eg. Note would be fine, but if you *really* need something more specific, you can declare it like https://example.org/vocab#AsideNote . It is good practice to define what that is in the /vocab document so that others (people or applications) can 1) understand what that means 2) and make it reusable.
# csarven Notice how the type oa:Motivation has "subClassOf": "http://www.w3.org/2004/02/skos/core#Concept" at https://www.w3.org/ns/oa.jsonld .
vasilakisfil, KevinMarks_, KevinMarks, timbl, fr33domlover and ajordan joined the channel
# fiatjaf https://github.com/99designs/httpsignatures-go is crap, dansup.
# fiatjaf csarven, perhaps someone has already defined the types I need and it's better if I reuse them instead of creating mine. how can I know that?
# nightpool[m] https://www.w3.org/TR/activitystreams-vocabulary/
# nightpool[m] otherwise, we're working on standardizing extensions to activitystreams but the process isn't rock-solid yet
# nightpool[m] there are other vocabularies out there but there's no compelling reason to use them in a federated web context IMO
# nightpool[m] yeah sorry i meant federated social network
# nightpool[m] like, if you were building a mainly-as2 piece of software, and wanted to add new features that thematically fit into as2-land, i think extending as2 is better then bolting on a hodgepodge of other vocabularies.
# csarven The example I've put at https://www.w3.org/TR/activitystreams-core/#example-using-multiple-vocabularies goes beyond the basic interaction.
# nightpool[m] for sure.
vasilakisfil joined the channel
# fiatjaf so, if I'm implementing that json parsing all by myself and manually, will everything break?
# fiatjaf I mean: do I have to consider all the attribute expansions json-ld supports?
# nightpool[m] json-ld is a subset of json so there's no issue in literally parsing it
# nightpool[m] interpreting it is a trickier proposition but you should be able to get away with mostly normal json stuff
# nightpool[m] there are a few gotchas to watch out for but it's not too bad
# fiatjaf yeah, but instead of getting an object like
{"@context": "https://www.w3.org/ns/activitystreams", "type": "Create"} I may someday get a {"https://www.w3.org/ns/activitystreams#type": "Create"}# nightpool[m] well so ActivityStreams does try to handle some of this
# fiatjaf how?
# nightpool[m] stuff that's mentioned in the activitystreams context document must be compacted before sending it across the net
# nightpool[m] so even though it's fine in pure json-ld, you'd never see https://www.w3.org/ns/activitystreams#Create in an as2-compliant document
# fiatjaf oh, that's good to hear
# fiatjaf but if I'm using a custom attribute I still may use it with or without @context and things can get confusing, right?
# nightpool[m] yeah
# nightpool[m] hasn't really been a problem for anyone so far but
# fiatjaf these standards are too broad
# fiatjaf perhaps they should be much more limiting
# fiatjaf and force people to do the things in only one possible way
# dansup heh
# nightpool[m] I mean
# nightpool[m] if you want to do things in the "one possible way", then you have a microblogging spec
# nightpool[m] and no way to build, e.g., forums with it
# nightpool[m] and of course if you find the uncertainty around pure json to be disturbing, you're welcome to compact the document into your context before accessing it
# nightpool[m] it's a reasonably simple algorithm, I'm told
# saranix likes this new nightpool
KevinMarks_ and KevinMarks joined the channel