#social 2017-11-22
2017-11-22 UTC
rowan joined the channel
# 
cwebber2 oh I see from https://www.w3.org/wiki/Socialwg/ActivityPub_PR
timbl, rowan_, rowan and htrob joined the channel
# 
xmpp-social [ajordan] bengo: I'm seeing HTTP 503
# bengo eplol ya I'm down right now :/
# bengo ajordan back
# xmpp-social [ajordan] Neat
xmpp-social and h joined the channel
# Chocobozzz Hi,
# Chocobozzz I'm sorry but I don't really understand how to distribute a like activity in the fediverse.
# Chocobozzz If a user A (on server A) creates a note, that is sent to followers user B (on server B) and user C (on server C), and then user B likes the note
# Chocobozzz -> the like activity is sent to server A, but how server C knowns that this note has a new like?
# 
rhiaro When B clicks 'like', their client knows that the original note was addressed to A's followers. The client includes this information - *and* adds A to 'to' (see section 6.1 Client Addressing) on the new Like activity, which is posted to B's outbox. B's server then carries out the instructions for outbox delivery (section 7.1.1) which involves finding all the adresses in to, bto, cc, bcc and audience, discovering *their* inboxes and posting the activity on. In
# rhiaro When A receive's B's like in A's Inbox, A's server carries out 7.1.2 (Forwarding from Inbox). In this case, A's server sees A's Followers collection in one of the addressing properties and can fetch the outbox of every actor in the Collection, and deliver to them. C is in this Collection, so C will get the Like.
# Chocobozzz Thanks for this very clear explanation rhiaro! :)
# Chocobozzz it would be very useful yes
# Chocobozzz makes sense!
h joined the channel
# 
sandro Looking over https://www.w3.org/wiki/Socialwg/2017-08-15-minutes#resolution06 it's odd how we did one Feature-at-Risk but not the other.
h, htrob, htrobinson and timbl joined the channel
# puckipedia hi hi
# puckipedia oh right, didn't think of that
h joined the channel
# puckipedia call is in 20-ish minutes?
h joined the channel
h and sivy joined the channel
# sivy o/
# puckipedia \o
# sivy pikcing up the kid but would like to lurk for the mtg
# sivy wow, have not been on IRC in dogs years
# sivy :)
h joined the channel
# puckipedia pfff finally got mumble audio to work ... took me like 5 minutes. hooray for linux
h joined the channel
# puckipedia anyways I'm in the mumble already
# melody i have a cold but i don't want to miss any more of these calls but i'll probably be muted 98% of the time because otherwise i'll just be sniffling into the mic
h joined the channel
RRSAgent joined the channel
# 
RRSAgent logging to https://www.w3.org/2017/11/22-social-irc
Zakim joined the channel
# puckipedia present+
# nightpool present+
# melody present+
# nightpool would scribe if they hadn't just woken up
# melody i haven't
# melody how does that work
# melody i'm a little nervous about that but i'll do my best
h joined the channel
# melody should i be capturing this sort of boilerplate convo?
# 
ben_thatmustbeme melody a few additional items to know, you can do things like TOPIC: <sometopic> to set the topic in the logs, , anyone can correct minutes with s/eror/error/
# melody cwebber2: activitypub is moving to PR which means that activitypub is as we see it ready to become a standard, but is waiting on management to approve it as a standard
# melody i'm really bad at scribing i'm sorry
# nightpool waves
# nightpool i'll take a look when I get a chance
# 
aaronpk https://github.com/w3c/websub/issues/138 and https://github.com/w3c/websub/issues/146 are the two issues
# melody aaronpk: with websub we've processed a bunch of feedback from the PR period, there are now two outstanding issues we need community feedback from -- it would be fantastic to get feedback from anybody using websub, i'll drop a link in the channel, and it'd be great to get input from the mastodon side, as it's critical to moving on to the next step of the spec
# melody i'm not sure if that's gonna be easier for me
# melody cwebber2: we're onto the final item of the agenda which is publishing which extensions are used by a server
# melody cwebber2: if you want to be able to send some sort of message and be sure the other side actually knows how to handle that message
# melody ... we have a certain amount of extension built into the spec already as general extension mechanisms
# melody ... but you can imagine we have a social karma extension and if we want to treat that on both sides as a transaction, and you would want to know if the other side will handle it
# melody i missed some middle here
# nightpool aaronpk: can you give a more concrete example of how this doesn't solve the problem even if it *feels* like it does?
# nightpool I agree but it feels like it can be more strongly worded.
# nightpool q+ to other failure
# melody aaronpk: this has been tried before but testing for extensions hasn't really worked well, it just looks like it solves a problem but doesn't actually, usually better to think of fallback behavior
# nightpool text-only b/c i just woke up, so maybe someone can relay?
# melody cwebber2: this might be more important when you are expecting an acknowledgement to a certain kind of message and are suprrised when one never arrives
# nightpool But this is important for other types of failures as well
# nightpool what if you try to pay someone, but their server went offline?
# nightpool We solved this for Follows with explicit Accepts and Rejects
# nightpool So extensions which need confirmation should have explicit confirmation.
# nightpool I don't think the problem needs to be any more complex then that.
# nightpool Unless there's something else I'm missing?
# nightpool fin.
# melody q+
# cwebber2 melody: I just wanted to add that one of the things that testing for extensions would allow you to do is not attempt delivery at all if a server does not support a specific extension, which could be important as a type of fallback behavior which could be important as a security-intensive thing if the server does not support whatever you're trying to publish
# nightpool +1 to sandro--just requiring a property on actors already covers everything this proposal could do
# melody sandro: mastodon had this failure mode with private messages before activitypub, JSON-LD extension mechanism covers everything this proposal could do
# melody cwebber2: the explicit ack might be important anyway because if you do a federated add to a collection and the collection isn't owned by your server we don't have any mechanism to have any sense of whether the add happened, only a request to add
# melody ... if i see that a request to add a photo to a shared curated album i don't actually know whether it happened i only see the request
# melody i'm sorry i missed that last bit
# nightpool cwebber2 I think sandro's point was a little stronger then you summarized it
# nightpool In that an "extension" endpoint is a complete subset to having a property, with that *same uri* that just says "true"
# nightpool We could probably move to a resolution to close this issue given it sounds like we have consensus?
# melody cwebber2: i agree we probably don't want to add another layer of indirection at this point
# nightpool Ah, sorry puckipedia was still typing that when you spoke up
# melody puckipedia: a while back we mentioned we might have a server actor for server-wide information, maybe for some extensions we can make sure that they are on the server actor
# melody cwebber2: if we go the direction of adding properties, there's no reason you couldn't use them on the server actor in that way
# nightpool there was a github issue.
# nightpool and vague conversation w/ the glich-soc people
# melody sandro: was there an actual problem somebody was having that prompted this issue?
# nightpool let me see if I can scare it up
# melody cwebber2: yes, but have not described it
# nightpool https://mst3k.interlinked.me/@Elizafox/1517781 is the thread
# nightpool https://github.com/swicg/general/issues/22 is the issue under discusion
# melody cwebber2: are we ready to close the issue?
# melody sandro: yes, we can point to these minutes and explain that it doesn't seem useful for the use cases so far
# nightpool C2S is maybe a point here we haven't brought up yet?
# xmpp-social [ajordan] Oh yikes completely forgot about the telecon... oops
# xmpp-social [ajordan] And I gotta pack now :/
# xmpp-social [ajordan] Have fun though!
# nightpool reading this thread/and the tagentially related glitch-soc issue by surinna https://github.com/glitch-soc/mastodon/issues/123
# melody cwebber2: the mechanism we're discussing seems to work just as well for client to server
# nightpool Right, that makes sense. Thanks.
# melody sandro: the client would just have to know where to look
# nightpool to be clear: this is the glitch fork, not the mastodon project
# nightpool ah yes. the "spam" filter
# nightpool sandro++
tantek joined the channel
# nightpool https://cybre.space/about/more
# nightpool https://octodon.social/about/more is another example
# melody should i start scribing again?
# melody nightpool: we have a new property on actors that say "this user has moved to this location" which is just displayed and does a soft redirect and the mastodon web UI disables the follow button
# melody cwebber2: i noticed that moved to was added to the AS namespace so this is a good time to talk about our extension process
# nightpool Given that none of the CG members that aren't part of other working groups can use the wiki, i'm still somewhat -1 on using it for extensions.
# melody cwebber2: we talked about letting implementers take the lead and try out changes before we decide whether to add something officially to AS
# melody sandro: could also add them on a provisional basis
# melody cwebber2: it seems less provisional if a major implementer releases something while it was in the spec
# melody sandro: we could make a wiki for the community group since almost anyone can join
# melody tantek: recommend against a community-group-specific wiki, when the group ends, it's hard to transition things and nobody has made it work in practice
# nightpool or having an "implemented" group or something
# melody cwebber2: so right now there's no mechanism for moving an extension away from "proposed"
# nightpool +1 to extend
# melody +1 to extend
# puckipedia will probably leave right now
# melody cwebber2: Given that people can't edit the wiki, propose we move the extension process into a github repository, people can use pull requests on a markdown document to contribute and discuss
# melody sandro: we could convert the existing document to markdown
# melody cwebber2: i don't think we need all the core stuff, we could do a document with just the extension info
# melody sandro: wouldn't it be easier if there was only one place to look up vocabulary?
# nightpool q+
# melody cwebber2: might be a lot to read through
# melody cwebber2: which repository should we use? ActivityPub, New Repo, ActivityStreams?
# melody cwebber2: going to create new repo
# melody nightpool: there may be vocabulary that we haven't thought through in a fully general context, liked moved to
# melody nightpool: if we make a new repository it should be for general activitypub extensions not just activitystreams
# melody i missed scribing some discussion about activitypub technically being an extension of activitystreams, so activitypub extensions are all activitystreams extensions
# melody nightpool: having seperate documents gives more room for adding historical information, context, and rationale
# melody nightpool: movedTo is a first step towards migration, just the first, easiest, simplest thing out there, when you want to move you specify the actor you want to move to, the actor provides a confirmation
# melody sandro: so this does not automatically move subscriptions/etc
# melody cwebber2: there was some talk of using a move activity to do the migration and subscriptions
h joined the channel
# nightpool cwebber2++
# RRSAgent I have made the request to generate https://www.w3.org/2017/11/22-social-minutes.html trackbot
# nightpool tantek: I understand that, but this is a first step for mastodon's implementation.
# melody i missed scribing some additional commentary at the end there
# nightpool It hasn't been released yet and my understanding is that we won't consider the feature "done" until it does also do the other things
# cwebber2 oh btw you were offline by the time I did it tantek, but "# yes" column up on https://activitypub.rocks/implementation-report/ now.
h joined the channel
# nightpool cwebber2: minutes link seems incorrect?
# nightpool Also, someone should put the minutes up on the wiki ^.^
# cwebber2 http://pandoc.amy.gy is down so I need to convert them manually
# nightpool huh, that's weird. pandoc.amy.gy seems to resolve for me, it just doesn't respond to port 80
# nightpool it's timing out on HTTP but it seems to be responding to dig just fine.....
# nightpool maybe they put cloudflare in front of it by accident, and now the DNS traffic is getting reflected to cloudflare which has no idea what to do about it?
# nightpool rhiaro: server is resolving for me at 178.62.197.214
h joined the channel
# xmpp-social [ajordan] Hey open question - does the non-normative convergence around JSON-LD signatures mean that "pure JSON" implementations MUST include a JSON-LD parser?
# xmpp-social [ajordan] Also FWIW pump.strugee.net is in DO NYC1 (iirc) and it seems fine
# nightpool ajordan: afaik you only need to do canonicalization, not parsing, but yes.
# xmpp-social [ajordan] Well "parsing"
# xmpp-social [ajordan] Doesn't canonicalization imply parsing contexts?
# nightpool this was a bit of a sticking point for mastodon and one of the reasons we're not super the biggest fans of it.
# xmpp-social [ajordan] Bearing in mind that I still don't understand JSON-LD lol
# xmpp-social [ajordan] Right, okay
# nightpool we do it cause it doesn't seem like there's a better way atm and this one is standarized
# nightpool ajordan: the signature verification code in mastodon is completely seperate from the actual "what is this activity code"
# nightpool one uses the JSON-LD libraries, the other doesn't.
# xmpp-social [ajordan] Yeah I think that's how we'll do it in pump.io too when we get there
# xmpp-social [ajordan] Just segregate it to a module marked "here be grues"
# nightpool FWIW the lds stuff isn't required for federation--we use HTTP signatures for that
# xmpp-social [ajordan] Right
# xmpp-social [ajordan] Ugh I'm so behind, this is a long way off for us anyway
# xmpp-social [ajordan] Well, depending
# xmpp-social [ajordan] We should get to a baseline of AP support pretty soon and then we'll have to tackle auth
# xmpp-social [ajordan] As the second step
# nightpool afaik you can always get around signing stuff by just fetching it from servers though
# xmpp-social [ajordan] Hm, good point
# nightpool so ¯\_(ツ)_/¯ on whether support is even useful.
# xmpp-social [ajordan] I mean you've traded strong identity keys for X.509/PKI but maybe it's worth it
# xmpp-social [ajordan] We'll see. Gotta ship baseline AP first
# xmpp-social [ajordan] We'll just keep our existing auth while that stabilizes
# puckipedia so actually I consider signing another reason: if you have no outbox, you could connect to any server, publish a message, then sign it to prove it's yours, then host it on that server
# xmpp-social [ajordan] You mean a static server?
# puckipedia you could host your actor object on your own domain, then host the objects on a shared server, for example, yeah
# xmpp-social [ajordan] But why not just host in the same place as your actor? Objects aren't that big
# xmpp-social [ajordan] Media might be, but that you can reference on a shared server
# puckipedia nomadic identity, object-hash-based IDs
# xmpp-social [ajordan] Idk I'm definitely not sure but right now I'm just not seeing the usecase
# xmpp-social [ajordan] So if we replaced HTTP URIs you mean
# puckipedia your ID could be https://puckipedia.com/ but your objects stored on https://social.puckipedia.com/ maybe even
# puckipedia which happens with Mastodon servers a bit, where webfinger on the root points to a subdomain
# puckipedia should you consider those to be in the same authority?
# xmpp-social [ajordan] Hmm
# xmpp-social [ajordan] Well so in that case I'd argue that since you're just dereferencing the ID from the apex domain it doesn't really count. Trying to figure out if there's same case where that wouldn't be true
# xmpp-social [ajordan] Idk I guess maybe I'm being too narrow-minded, not sure
# xmpp-social [ajordan] Just want to avoid building out something with no *real* usecases
# xmpp-social [ajordan] *cue a wild tantek appearing*
# puckipedia so I think signing objects is still a good idea to do even for normal retrieval
# puckipedia anyways,
{"type": "Person", "id": "https://www.example.com", "outbox": "https://social.example.com" }# puckipedia is this the same origin? :P
# puckipedia or, ehm, bad example
# xmpp-social [ajordan] tantek: amirite
# puckipedia
{"id": "https://example2.com", "type": "Note", "attributedTo": "https://www.example.com", "content": "Hello"} - how do you verify that this object was created by the above person# nightpool wait is what the same origin
# puckipedia nightpool: www.example.com and social.example.com
# xmpp-social [ajordan] Hm yeah so that makes sense but two things
# nightpool well, I mean the glib answer is "you get it posted to your inbox with HTTP Signatures"
# puckipedia nightpool: what if Alice as:Announces the post?
# xmpp-social [ajordan] 1. While you'd definitely need signatures for that case, I'm still not convinced that would actually come up in practice (though definitely could be wrong)
# puckipedia I can make Kroeg do this without even changing code
# xmpp-social [ajordan] 2. What's the threat model? You're still vulnerable to DoS
# puckipedia cwebber2: well, the LD signatures run on the announce don't verify the object that is announced
# xmpp-social [ajordan] cwebber2: but the question is whether refetching from the origin is Good Enough ™
# puckipedia (or the server is down currently)
# xmpp-social [ajordan] Ahhhhhh okay
# puckipedia I myself would like to see every object signed separately to be Future-Proof(TM)
# xmpp-social [ajordan] Sorry, I have a vague memory of us discussing this so I know I'm rehashing (ha!) things
# xmpp-social [ajordan] (very distracted atm because of some really nasty stuff in my personal life :/ )
# xmpp-social [ajordan] cwebber2: not DDoS
# xmpp-social [ajordan] DoS
# xmpp-social [ajordan] The scenario we were discussing is if your actor is on a server you control but everything else is in a shared server but it's signed. I wasn't convinced people would actually want that in practice
# xmpp-social [ajordan] cwebber2: thanks, I appreciate it
bengo joined the channel
# puckipedia or people not wanting to host e.g. an AP server, but still use their own domain as ID
# xmpp-social [ajordan] We thought that?
# xmpp-social [ajordan] Lol I'm sure
# xmpp-social [ajordan] Right that totally makes sense
# xmpp-social [ajordan] But if we're at the point where "another domain" is so untrusted you need to sign all your stuff
# xmpp-social [ajordan] But if it's a domain *you picked*
# xmpp-social [ajordan] Sure
# xmpp-social [ajordan] Ahhh yes that makes sense now
# xmpp-social [ajordan] Because there's no canonical location for "here are the domains that are allowed to speak for me"
# xmpp-social [ajordan] Ooookay. Got it.
# xmpp-social [ajordan] So (and I'm NOT suggesting we do this but) it sounds like you could just specify that
# xmpp-social [ajordan] Like an array in the Actor or something
# xmpp-social [ajordan] And then you wouldn't need the signatures anymore
# melody if you wanted a location for "here are the domains that are allowed to speak for me" wouldn't it pretty much have to be the domain of the actor's ID?
# xmpp-social [ajordan] Ofc, and I'm not suggesting we specify it
# xmpp-social [ajordan] For that reason and because it just feels shaky compared to strong cryptography
# xmpp-social [ajordan] melody: yeah, but that fits the situation we're discussing
# melody i was just checking my understanding mostly, trying to follow this conversation
# xmpp-social [ajordan] ? sounds good
# xmpp-social [ajordan] Oh actually do you know what else
# melody i'm bad at crypto but *really* interested in the auth implications of AP for my eventual implementation
# melody so this seems important to grok
# nightpool cwebber2: what kind of access control problems do you predict here?
# xmpp-social [ajordan] Domain-based trust doesn't work. Because what if you have shared hosting on the same domain and each customer gets a subpath
# xmpp-social [ajordan] melody: right
snarfed joined the channel
# xmpp-social [ajordan] Though tbh the actual crypto isn't super interesting here, it's mostly just signature stuff we (meaning the tech community, not #social) have been doing for ages
# xmpp-social [ajordan] Lol collections
# nightpool I mean, the server that publishes the collection?
# nightpool from a AP perspective, the person who can actually change what is returned for that object
# nightpool cwebber2: well, they'd have to send those activities to that server then?
# xmpp-social [ajordan] nightpool: but you can't preemptively determine access
# nightpool in some sense there is no way to model an ACL for activity pub because only one person can ever change what is returned by resolving a given DNS path
# xmpp-social [ajordan] You'd have to try/catch
# nightpool forwarding can't add new recepients that aren't explicitly addressed
# nightpool that's part of the spec mastodon breaks
# nightpool cwebber2: on a different topic, I wrote up a bit about movedTo.
# nightpool yeah
# nightpool in the meantime you can take a look here: https://gist.github.com/nightpool/21fb737babb2f8714d911236e21b05e7
# nightpool left a comment about wanting to include possible redirects/delivery/etc solutions but not being confident in their correctness currently.
# nightpool will probably integrate that into the text itself when I make the PR
# ben_thatmustbeme looks at the chat history
# ben_thatmustbeme turns and leaves immediately
# xmpp-social [ajordan] Lolll
# xmpp-social [ajordan] Same tho
# 
tantek next week's SWWG telcon agenda page up: https://www.w3.org/wiki/Socialwg/2017-11-28
# 
Loqi Tantekelik made 1 edit to [[Socialwg/2017-11-28]] https://www.w3.org/wiki/index.php?diff=105261&oldid=0
# xmpp-social [ajordan] Thx tantek
# xmpp-social [ajordan] tantek: the bullets starting with PTD, SWP, etc. are just the reasons we need to have December telecons, right? Not actually on the agenda?
# xmpp-social [ajordan] ben_thatmustbeme: should JF2 be on that list?
# ben_thatmustbeme yes, i suppose it should
# xmpp-social [ajordan] If you don't feel it's ready or anything like that we could move it to the SocialCG
# xmpp-social [ajordan] Since it's not REC-track
# xmpp-social [ajordan] Cool, thx
# xmpp-social [ajordan] Define "snapshot"
# xmpp-social [ajordan] Oh misread NOTE as WD
# xmpp-social [ajordan] Why though? SocialCG can publish notes so why wouldn't we just continue incubating it there?
# xmpp-social [ajordan] Ahhhhhhh interesting
# xmpp-social [ajordan] I must've misremembered. That's unfortunate
# xmpp-social [ajordan] Snapshotting makes a lot more sense now tho
# xmpp-social [ajordan] Oh I need to read the minutes from yesterday and today don't I
# Loqi Tantekelik made 1 edit to [[Socialwg]] https://www.w3.org/wiki/index.php?diff=105262&oldid=105222
# tantek re-reads the charter https://www.w3.org/2013/socialweb/social-wg-charter.html to see how we are doing / have done on Goals
# xmpp-social [ajordan] Could easily be a part of the NOTE series we do
# tantek captured: https://github.com/dissolve/jf2/issues/36
# 
ajordan https://chat.indieweb.org/social/2017-11-22#t1511339628912000 oh god I just realized
# erincandescent ajordan: ActivityPub (and the pump.io protocol) are kinda just SMTP over HTTP
# erincandescent Also SMTP/IMAP can't list all the e-mails I've ever sent to anyone else
# erincandescent yes
# erincandescent Its on the server but your client puts it there
# erincandescent When you send an e-mail, your client SMTPs it and then stuffs it into sent
# erincandescent The SMTP server does not stuff e-mails into sent
# erincandescent No, with AP the act of sending something and adding it to your outbox is atomic
# erincandescent No
# erincandescent You send your e-mail via SMTP, and *then* your client (by convention) dumps a copy in "Sent Items"
# erincandescent More importantly I can't login to tantek's server via IMAP and read his Sent Items
# erincandescent tantek: Yes, but in the social web we call it "reading somebody's feed/blog"
# erincandescent . o O (JMAP)
# aaronpk JMAP is already a thing http://jmap.io/
# erincandescent JMAP replaces IMAP and SMTP MSP, so JMAP is ActivityPub for e-mail :P
# erincandescent yeah
# Loqi Tantekelik made 1 edit to [[Socialwg/2017-11-21]] https://www.w3.org/wiki/index.php?diff=105263&oldid=105249
# erincandescent Honestly fetching won't fix anything. Spammers will just setup their own servers
# erincandescent SMTP: Hah, can't require TLS. Definitely can't require valid TLS certs
# erincandescent You can totally still run your own mail server
# erincandescent Not really? So many companies run in house
# puckipedia IPv6 SMTP against gmail is really complicated against
# puckipedia apparently*
# erincandescent Honestly I've never seen an enterprise using GMail. Though Office365 yes
# erincandescent aaronpk: In my corner of the industry its all Exchange and probaly Office365 and Skype for Business ...
# puckipedia ajordan: oh aha, I think you need a valid PTR record :<
# erincandescent Dynamic IPs are normally bad because most ISPs enter them into DNSBLs
# erincandescent ajordan: Spamhaus Policy Blocklist is dynamic IPs (as marked by ISPs)
# erincandescent "Policy" = netblock owner indicates this IP should not be sending e-mail
# puckipedia yep. I am in the PBL, but not in the SBL or XBL
# erincandescent lol I just pulled the MX records of 6 of our customers, 5 in house, 1 Office365
# puckipedia woooow debugging Kroeg is slow
# puckipedia like. really really slow.
# puckipedia "next": "http://localhost:5000/user/28839131/outbox?cursor=-1?cursor=925512232439631872",
# puckipedia eh I'll call this an improvement
# puckipedia yeah!
# cwebber2 tantek: btw is there anything else to be done other than what rhiaro already did on https://www.w3.org/wiki/Socialwg/ActivityPub_PR ?
# tantek in https://www.w3.org/wiki/Socialwg/ActivityPub_PR#Requirements, it ought to cite the deliverables from the charter which are being satisfied
# tantek and even quote from the scope, since that's what you're helping to satisfy https://www.w3.org/2013/socialweb/social-wg-charter.html#scope
# tantek almost literally: "A social API should include the ability to embed third-party information and share social data between web applications. The API should re-use the social data transfer syntax and may allow some interaction with the federation protocol. The API should also be extensible in terms of the items of interest expressible by the data format."
# ajordan https://twitter.com/NYTMinusContext but for #social and on a federated network (duh)
# cwebber2 > Embedded Experiences: When a user is involved in a social process, often a particular action in a status update may need to cause the triggering of an application. For example, a travel request may need to redirect a user to the company's travel agent. Rather than re-direct the user, this interaction could be securely embedded within page itself.
rowan joined the channel
# tantek aforementioned example of iframe embedding a third party service to show RSVPs on my event posts http://tantek.com/2017/319/e1/homebrew-website-club (including an RSVP from ajordan)
# cwebber2 oh here's micropub's https://www.w3.org/wiki/Socialwg/Micropub_PR
timbl joined the channel