15:02:09 <RRSAgent> RRSAgent has joined #social
15:02:09 <RRSAgent> logging to http://www.w3.org/2017/06/21-social-irc
15:02:11 <trackbot> RRSAgent, make logs public
15:02:11 <Zakim> Zakim has joined #social
15:02:13 <trackbot> Zakim, this will be SOCL
15:02:13 <Zakim> ok, trackbot
15:02:14 <trackbot> Meeting: Social Web Working Group Teleconference
15:02:14 <trackbot> Date: 21 June 2017
15:03:12 <cwebber2> present+
15:03:13 <puckipedia> present+
15:03:15 <Gargron> present+
15:03:16 <ben_thatmustbeme> present+
15:04:38 <cwebber2> scribenick: cwebber2
15:04:59 <ben_thatmustbeme> sorry, just back in a minute
15:05:25 <cwebber2> puckipedia: hello, I'm Puck, I'm 17 and I'm building an ActivityPub implementation in .NET, and it's pretty far so far
15:05:45 <cwebber2> Gargron: have you tried to federate with Mastodon?  I saw someone trying to connect in our logs
15:05:54 <cwebber2> puckipedia: probably
15:06:18 <cwebber2> topic: content warnings
15:06:28 <cwebber2> Gargron: I still assert that a content warning is effectively a summary
15:06:49 <ben_thatmustbeme> back
15:07:01 <jaywink> present+ (at least part of meeting)
15:07:31 <ben_thatmustbeme> scribenick: ben_thatmustbeme
15:07:52 <ben_thatmustbeme> TOPIC: tags
15:08:23 <ben_thatmustbeme> cwebber2: should we end up having a seperate type and wrapping it?
15:08:52 <ben_thatmustbeme> Gargron: would it be a top level type? it would change the meaning of the content, or instead another string like a hash
15:09:02 <cwebber2> {"summary": {"type": "ContentWarning", "name": "Steven Universe spoilers"}}
15:09:04 <cwebber2> OR
15:09:11 <cwebber2> {"tag": [{"type": "ContentWarning", "name": "Steven Universe spoilers"}]}
15:09:31 <ben_thatmustbeme> cwebber2: in the tag example (in irc) you want some sort of ID too
15:10:08 <ben_thatmustbeme> Gargron: it feels like the tag approach is not the way to go with this.  Its not the same type of thing, its not a hashtag or a mention, that would be a bit weird
15:10:26 <ben_thatmustbeme> Gargron: I haven't looked at all the parsing of it, the parsing of this is going to be complicated
15:10:53 <ben_thatmustbeme> cwebber2: thats true, if you open up summary to be just a string vs contain other objects
15:11:17 <ben_thatmustbeme> ... one reason to use a tag, is to allow people to decide certain types of things they are ok with vs not ok with
15:11:38 <ben_thatmustbeme> ... lets them set up their client to auto show vs auto block
15:11:51 <ben_thatmustbeme> Gargron: if the name is free text, are you going to categorize it in any way
15:12:13 <ben_thatmustbeme> cwebber2: yeah, you would want to, and maybe thats just incomaptible the way mastodon is going
15:12:38 <ben_thatmustbeme> Gargron: there are a lot of ways trigger warnings can be used, and some people are not ok with trigger warnings
15:13:08 <ben_thatmustbeme> ... some use them for spoilers and some for trigger warnings.  it feels like it is more free text
15:13:31 <ben_thatmustbeme> puckipedia: it feels like ... for example images are hidden like a nsfw tag?
15:13:47 <puckipedia> (hidden with an invisible nsfw hashtag)
15:14:47 <ben_thatmustbeme> Gargron: i used nsfw for compatiblity with what they had.  it conflicts for user and system space information.  If you add a NSFW tag by hand, it has the same effect as the checkbox, but its not obvious that it does that
15:15:12 <ben_thatmustbeme> ... maybe its okay, and the tag content just becomes the catch all
15:16:00 <ben_thatmustbeme> (digression to location tags and those being their own thing)
15:16:33 <ben_thatmustbeme> cwebber2: it also may be that if we tried to move it to tags, we might see a user revolt
15:16:55 <jaywink> I really don't get the summary example (of the two above). In Diaspora for example, "sensitive" content is indicated by the #nsfw tag, which to me feels appropriate here too. What it is called is irrelevant if the tag is "typed" as ContentWarning. Ie the type feels more important here than the actual tag name. But then, why not just make it a boolean "sensitive: true/false"?
15:16:58 <ben_thatmustbeme> Gargron: the goal would be to have it not change Mastodon at all, just change the representation underneath
15:17:19 <ben_thatmustbeme> cwebber2: that means you wouldn't really have it in mastodon.
15:17:25 <cwebber2> jaywink, a boolean might work
15:17:54 <ben_thatmustbeme> Gargron: its really somewhat a domain specific issue.  I am more just concerned about encoding it in a way that others can read the same.
15:18:03 <ben_thatmustbeme> ... it might not be necessary for content warnings
15:18:26 <ben_thatmustbeme> cwebber2: if mastodon isn't going to use it, then it may be the case that leaving it in summary makes sense
15:18:58 <ben_thatmustbeme> Gargron: on the other hand, the sensative content thing, i am all for the sensative attribute on documents.  there is no other way that can be encoded, it needs to be an attribute
15:19:14 <cwebber2> jaywink, want to present+?
15:19:26 <ben_thatmustbeme> cwebber2: we talked about that in the WG
15:19:37 <jaywink> (thought I did, maybe there can't be other text on the line ;))
15:19:39 <jaywink> present+
15:19:47 <zatnosk> Hello, I'm zatnosk@manowar.social on mastodon. Listening in as interested person :)
15:19:54 <cwebber2> https://github.com/w3c/activitypub/issues/231
15:19:55 <Loqi> [cwebber] #231 "Sensitive Media" tag
15:19:55 <ben_thatmustbeme> Zakim: who is here?
15:20:01 <ben_thatmustbeme> Zakim, who is here?
15:20:01 <Zakim> Present: cwebber, puckipedia, Gargron, ben_thatmustbeme, (at, least, part, of, meeting), jaywink
15:20:01 <tantek> FYI for all folks here contributing to specs (e.g. CG notes / drafts) who aren't W3C members of Invited Experts already: https://w3c.github.io/repo-management.html
15:20:03 <Zakim> On IRC I see RRSAgent, Gargron, zatnosk, tweb, tantek, timbl, KevinMarks, ajordan, fkleedorfer, jankusanagi_, bwn, nightpool, ben_thatmustbeme, cwebber2, KjetilK__, albino,
15:20:03 <Zakim> ... csarven, DenSchub, sknebel, sandro, rhiaro, astronouth7303, dwhly, bitbear, jaywink, jet, mattl, bigbluehat, saper, aaronpk, tcit, wilkie, MMN-o, Loqi, puckipedia, trackbot,
15:20:03 <Zakim> ... lambadalambda, raucao, saranix
15:20:23 <ben_thatmustbeme> present- (at least part of meeting)
15:20:25 <ben_thatmustbeme> Zakim, who is here?
15:20:25 <Zakim> Present: cwebber, puckipedia, Gargron, ben_thatmustbeme, jaywink
15:20:27 <Zakim> On IRC I see RRSAgent, Gargron, zatnosk, tweb, tantek, timbl, KevinMarks, ajordan, fkleedorfer, jankusanagi_, bwn, nightpool, ben_thatmustbeme, cwebber2, KjetilK__, albino,
15:20:27 <Zakim> ... csarven, DenSchub, sknebel, sandro, rhiaro, astronouth7303, dwhly, bitbear, jaywink, jet, mattl, bigbluehat, saper, aaronpk, tcit, wilkie, MMN-o, Loqi, puckipedia, trackbot,
15:20:27 <Zakim> ... lambadalambda, raucao, saranix
15:20:31 <jaywink> sorry :(
15:20:57 <ben_thatmustbeme> cwebber2: i would be okay it not being a tag, and being a boolean property attached to the object
15:21:02 <jaywink> welcome zatnosk :)
15:21:11 <ben_thatmustbeme> Gargron: if we are just encoding Mastodon information 1-to-1
15:21:15 <ben_thatmustbeme> then yes, that would work
15:21:22 <ben_thatmustbeme> but i think it might make sense on the document
15:21:43 <ben_thatmustbeme> even if mastodon doesn't use that, maybe someone else will, like if one image is sensative, but the others aren't
15:22:06 <ben_thatmustbeme> cwebber2: if we move to bool prop, there is nothing stopping it from being on the sub objects
15:22:17 <saranix> defintely not boolean. The semantics are not boolean. The semantics are client/user dependant (a client/user may want to use it to influence sorting score)
15:22:38 <ben_thatmustbeme> cwebber2: i suppose the reason was we didn't have time and tags was simpler
15:22:50 <ben_thatmustbeme> ... but the GW was just extended, so maybe thats ok
15:22:59 <ben_thatmustbeme> puckipedia: i think the boolean would be nice
15:24:16 <ben_thatmustbeme> cwebber2: lets actually capture this as a resolution
15:24:40 <cwebber2> PROPOSED: Add a "sensitive" tag to ActivityPub in next revision, a boolean, to resolve https://github.com/w3c/activitypub/issues/231 (which can be used in addition to content warnings, etc)
15:24:40 <Loqi> [cwebber] #231 "Sensitive Media" tag
15:24:48 <cwebber2> +1
15:24:48 <Gargron> +1
15:24:50 <puckipedia> +1
15:24:57 <jaywink> +1
15:25:00 <saranix> -1
15:25:08 <ben_thatmustbeme> +0 as i don't know all the details of it
15:25:22 <ben_thatmustbeme> cwebber2: we have a minus 1 from saranix
15:25:38 <cwebber2> saranix, we're not talking about Content Warnings at this point btw
15:26:00 <cwebber2> saranix, specifically about supporting sensitive as a separate boolean, as opposed to having an "official" sensitive/nsfw type tag
15:26:01 <ben_thatmustbeme> Gargron: saranix isn't on the call, so maybe missed some context, its not content warning, but just sensative
15:26:09 <saranix> In my protocol, both content warnings and "sensitive" are handled by a special tag taxonomy
15:26:19 <saranix> ... the same tag taxonomy
15:26:21 <saranix> ... for both
15:27:01 <nightpool> hey, sorry all, just woke up
15:27:17 <cwebber2> nightpool, hey welcome :)
15:27:20 <ben_thatmustbeme> cwebber2: lets just continue, as i'm not sure thats resolved then
15:27:21 <cwebber2> https://github.com/swicg/general/issues/6
15:27:21 <Loqi> [Gargron] #6 Hashtag representation
15:27:41 <ben_thatmustbeme> TOPIC: formatting of tags
15:28:19 <ben_thatmustbeme> cwebber2: we talked about this in the WG, evan basically said i don't think we need to specify this itself, but the AP community group needs to come to some consensus on this
15:29:16 <ben_thatmustbeme> Gargron: i think the thing is that tags are just strings, there isn't really an "id".  But with objects, there is an id, for links there is a href, where does that tag live
15:29:46 <nightpool> q+ about ids
15:29:54 <nightpool> fuck
15:30:01 <nightpool> q- about, ids
15:30:07 <nightpool> q+ to talk about ids
15:30:10 <ben_thatmustbeme> cwebber2: for mentions, those do have an id, but for general string style tags, i think (even evan) said that most tags do exist in some global namespace
15:30:34 <ben_thatmustbeme> ... the possibilities are to use http ids and use fragments
15:30:40 <cwebber2> https://tagnamespace.example#foo
15:30:44 <ben_thatmustbeme> ... its possible to use ostatus tags
15:30:59 <ben_thatmustbeme> Gargron: Mastodon doesn't use the groups parts of ostatus
15:31:29 <saranix> +1 uri "https://tagnamespace.example#foo"
15:31:52 <ben_thatmustbeme> cwebber2: i think those would work well as mentions
15:32:07 <ben_thatmustbeme> cwebber2: is the difference between having things that don't have uri vs do
15:32:13 <ben_thatmustbeme> Gargron: yes
15:32:50 <ben_thatmustbeme> cwebber2: part of timbl's whole idea was that fragments are supposed to refer to things that you might not actually be able to retrieve it
15:33:05 <ben_thatmustbeme> like gps coords then fragment for the bike at that location
15:33:07 <tantek> of course no tags have ever worked that way in practice on the web
15:33:20 <tantek> e.g. rel=tag tags worked with the last segment of a URL, not #
15:33:31 <tantek> similarly, WordPress categories
15:33:32 <tantek> etc.
15:33:35 <ben_thatmustbeme> so this works in that sense, but ...((??)
15:33:55 <ben_thatmustbeme> Gargron: how about just using the same one for the public collection, then just tacking on the hashtag at the end of htat
15:34:15 <ben_thatmustbeme> cwebber2: you risk people throwing in things the refer to real activitystreams properties
15:34:26 <tantek> I'm opposed to using such URLs for anything persistent since fragments are only interpreted on clients
15:34:26 <ben_thatmustbeme> cwebber2: i think it would need its own seperate base url
15:34:33 <ben_thatmustbeme> q?
15:34:37 <cwebber2> q?
15:34:39 <cwebber2> ack nightpool
15:34:39 <Zakim> nightpool, you wanted to talk about ids
15:34:42 <tantek> I think it's fundamentally bad design
15:35:12 <tantek> and frankly, not what the web has evolved to use
15:35:16 <ben_thatmustbeme> nightpool: saying a hashtag doesn't have an ID doesn't really ring true to me,
15:35:31 <ben_thatmustbeme> every hashtag i've seen links to something
15:35:49 <cwebber2> welcome sandro
15:35:52 <ben_thatmustbeme> cwebber2: are you talking about how servers often have a collection
15:36:01 <ben_thatmustbeme> nightpool: they always seem to link to one location
15:36:17 <tantek> e.g. https://twitter.com/hashtag/socialweb
15:36:40 <ben_thatmustbeme> Gargron: its just a keyword, you may filter that by local only or all known posts, but its just a slice of everything
15:37:06 <ben_thatmustbeme> nightpool: that just means we need to standardize the names better, instead we should have a type that has a specific name field
15:37:13 <ben_thatmustbeme> cwebber2: we have that
15:37:35 <ben_thatmustbeme> nightpool: but the way to specify that its actually...
15:38:01 <ben_thatmustbeme> cwebber2: you end up with blank nodes which go to np-complete type problems
15:38:28 <ben_thatmustbeme> nightpool: it specifies which instance that hash tag comes from, which i think is useful
15:38:43 <ben_thatmustbeme> Gargron: you don't have different hashtags you just have one
15:38:45 <saranix> http://somesite.example/foodie-tags#flavors -- fetching http://somesite.example/foodie-tags would pull the whole taxonomy, #flavors would point to the fragment within the spec for that tag?
15:38:52 <ben_thatmustbeme> nightpool: suppose its like a group
15:38:55 <cwebber2> q?
15:38:56 <cwebber2> q+
15:39:14 <ben_thatmustbeme> Gargron: they aren't groups, you would need to have a way to get a hashtag to a certain server
15:39:17 <cwebber2> ack cwebber2
15:39:26 <ben_thatmustbeme> cwebber2: i suggest we use the queue as we have a lot of people now
15:40:02 <ben_thatmustbeme> to put this is prospective, where should it point, do we point to some abstract place, or per instance
15:40:08 <nightpool> tantek: something we discussed this week was ways that JSON=LD specifies for resolving fragment identifiers
15:40:45 <ben_thatmustbeme> lets say we have a federated situation, suppose on each our instances we both tag our #food
15:41:15 <ben_thatmustbeme> do you expect to see your own server's local knowledge, or do you assume you will see only the remote server's
15:41:25 <ben_thatmustbeme> nightpool: i think that depends on the situation
15:41:41 <ben_thatmustbeme> sometimes you want to see only those for an account, sometimes all globally
15:41:56 <ben_thatmustbeme> i think the best is for like federated and local timeline
15:41:58 <cwebber2> q?
15:41:59 <saranix> This problem cropped up in Zot vs Diaspora. Diaspora treats all tags as global, zot treats them as local. When I support both protocols, I have a global tax and a site tax to distinguish.
15:42:01 <cwebber2> ack cwebber
15:42:11 <ben_thatmustbeme> you have these resources that are fused into local resourse
15:42:23 <ben_thatmustbeme> cwebber2: any other thoughts on that?
15:42:44 <saranix> I think as far as the spec goes, there should be a specified url (taxonomy) for global tags
15:42:50 <ben_thatmustbeme> Gargron: mastodon does turn all hashtags into a local link, leaving your instance to another place, is bad user experience
15:43:09 <ben_thatmustbeme> a lot of mastodon is built on 'we fetch all the data that we need'
15:43:10 <nightpool> to be clear, what I meant was "sometimes you want to see your local instance's view of the hashtag, sometimes you want to open up another instance's  view of the hashtag"
15:43:24 <ben_thatmustbeme> cwebber2: does it have the sense that we are transforming the global in to the local?
15:43:42 <zatnosk> I need to leave now. It was nice to follow along :)
15:43:58 <ben_thatmustbeme> Gargron: on one hand yes, we do transform the global into the local
15:43:59 <cwebber2> thanks for coming zatnosk :)
15:44:01 <nightpool> i.e. sometimes you want to go to your local /tag/A and sometimes you want to go to the instance that it came from.
15:44:37 <zatnosk> zatnosk has left #social
15:44:44 <ben_thatmustbeme> Gargron: the way mastodon works, you only load what you need, a small instance can exist because it only gets what it needs
15:45:02 <ben_thatmustbeme> i am against having anything fully global that puts that extra weight on small instances
15:45:20 <ben_thatmustbeme> cwebber2: if we wanted to be able to distinguish both, we have id and url
15:45:34 <ben_thatmustbeme> we could point the id at the global version and the URL at the global version
15:45:39 <ben_thatmustbeme> <ben_thatmustbeme> that sounds really odd
15:45:46 <saranix> Users should have the choice, they should decide if they want their tag to be in the global namespace, or the site namespace, or some other namespace. This is what my protocol allows.
15:46:15 <ben_thatmustbeme> Gargron: i suppose what matters for me is I don't think Mastodon will use the id or the url for parsing tags out of json, its going to use the name tag
15:46:29 <ben_thatmustbeme> its going to be redundant to use those other tags for me
15:46:29 <nightpool> q+
15:46:34 <ben_thatmustbeme> s/tags/fields/
15:46:53 <ben_thatmustbeme> Gargron: the only thing we need ids for is the metadata
15:46:57 <cwebber2> q?
15:46:58 <cwebber2> q+
15:47:08 <cwebber2> ack nightpool
15:47:12 <jaywink> +1 Gargron I would do the same even if tag had an url - it's kinda irrelevant to building local presentation
15:47:21 <cwebber2> q-
15:47:37 <ben_thatmustbeme> nightpool: id on't think the issue is how we represent it, its that we don't have tags in our ontology at all
15:47:45 <ben_thatmustbeme> so a hashtag type is the way to solve it
15:47:50 <ben_thatmustbeme> Gargron: i agree completely
15:48:28 <ben_thatmustbeme> You can tell if something is a mention, because it has a mention type, the way its in AP spec, you can't tell if its a tag or something else
15:48:57 <cwebber2> PROPOSED: Add a Tag type (to capture the most common type of tags, and distinguish from Mention/etc)
15:49:00 <cwebber2> +1
15:49:02 <ben_thatmustbeme> puckipedia: i already experiemented with a tag type as i needed it
15:49:02 <nightpool> +1
15:49:04 <jaywink> +1
15:49:05 <puckipedia> +1
15:49:17 <ben_thatmustbeme> +1 seems pretty reasonable
15:49:29 <jaywink> tags are the butter of social media <3
15:49:36 <ben_thatmustbeme> puckipedia++ for citing implementation experience
15:49:36 <Loqi> puckipedia has 2 karma
15:49:41 <cwebber2> RESOLVED: Add a Tag type (to capture the most common type of tags, and distinguish from Mention/etc)
15:49:51 <nightpool> present+
15:49:56 <Gargron> +1
15:50:10 <jaywink> even linkedin has hashtags these days which was a shock to me
15:50:28 <cwebber2> q?
15:51:10 <cwebber2> topic: webfinger
15:51:42 <ben_thatmustbeme> cwebber2: we did agree that webfinger was important to resolve within the scope of AP
15:51:58 <ben_thatmustbeme> ... we have yet to answer how webfinger fits in
15:52:10 <ben_thatmustbeme> q+
15:52:17 <cwebber2> ack ben_thatmustbeme
15:54:06 <nightpool> q+ to talk about userless actors
15:54:12 <ben_thatmustbeme> ben_thatmustbeme: for me the concern has been to replace it with an improvement
15:54:22 <ben_thatmustbeme> cwebber2: its not going to disappear soon
15:54:41 <ben_thatmustbeme> i know many projects rely on it
15:54:53 <ben_thatmustbeme> sites like mastodon and gnusocial and diaspora still use it
15:54:56 <ben_thatmustbeme> q+
15:55:03 <cwebber2> ack nightpool
15:55:03 <Zakim> nightpool, you wanted to talk about userless actors
15:55:10 <ben_thatmustbeme> cwebber2: we need to give some sort of compatability route for them
15:55:45 <ben_thatmustbeme> nightpool: mastodon has had some problems with webfinger, (using external services)
15:55:46 <cwebber2> ben_thatmustbeme raised concerns about the difficulty of adopting webfinger
15:56:03 <cwebber2> and the problems for people on single-user sites, etc
15:56:08 <ben_thatmustbeme> nightpool: having actors that are a whole domain is such a niche market
15:56:24 <ben_thatmustbeme> <ben_thatmustbeme> nightpool i would HIGHLY disagree with that
15:56:39 <cwebber2> q?
15:56:40 <cwebber2> ack ben_thatmustbeme
15:56:42 <saranix> +1 https://github.com/w3c/activitypub/issues/194#issuecomment-294930878
15:56:45 <Loqi> [evanminto] @cwebber Is there any reason why the reverse (AP-to-WF) lookup can't just pass the ActivityPub URI as the `resource` param of the WebFinger endpoint? That would seem like a really clean way to do the translation if the WebFinger spec allows it.
15:56:45 <Loqi> ##...
15:56:46 <cwebber2> scribenick: cwebber2
15:57:09 <ben_thatmustbeme> nightpool: i would say if we have a simpler protocol that doesn't support userless domains we should look at the simpler
15:57:18 <cwebber2> puckipedia: I do think that user domains could include subdomains, such as user.mastodon.example, and that may be simpler for some people
15:57:29 <ben_thatmustbeme> puckipedia: the same could be done via subdomains
15:57:44 <ben_thatmustbeme> sandro: this covers a lot of existing sites that aren't social
15:57:55 <ben_thatmustbeme> ... i'd like to see them involved
15:58:03 <cwebber2> sandro: another argument for user-less domains are a large number of existing websites that I would like to see become entities.  every business / school / etc has some way of talking to the world and we have no way to figure out what that is.  currently there's no computer readable protocol to figure that out
15:58:04 <cwebber2> q?
15:58:05 <ben_thatmustbeme> right now there is no computer readable method to do that
15:58:14 <ben_thatmustbeme> ... i think its more than that
15:59:16 <nightpool> q+
15:59:49 <cwebber2> ben_thatmustbeme: I'm not saying we should try to make it a ton more complex to support it, the enconding of webfinger right now is more complex in the discovery, the definition is user@host, if you leave off user at that and have host just be the domain, and even subfolders, it's backwards compatible (and we need to be backwards compatible to webfinger) but even the change of allowing hosts to have a path, and doesn't add a lot of
15:59:49 <cwebber2> complexity.  the only place it adds a lot of complexity is when you want to reference a local user, and I don't know if that's a local url or at some domain
15:59:58 <nightpool> hosts are allowed to not have periods also
15:59:59 <cwebber2> sandro: the presence of a period should tell you the difference
16:00:07 <cwebber2> ben_thatmustbeme: webfinger allows periods
16:00:11 <cwebber2> q?
16:00:12 <cwebber2> q+
16:00:28 <cwebber2> sandro: gmail allows periods but they're ignored
16:00:52 <puckipedia> q+
16:01:18 <cwebber2> nightpool: the other thing I wanted to register is an ideological disagreement to the idea of social actors that aren't users, I'm not interested in building a social network for coprorations.  I'm not saying the group should hold that up, but I don't think that, aside from bots, we don't have things like brands on mastodon, and ideologically I agree with that
16:01:26 <cwebber2> ack nightpool
16:01:28 <ben_thatmustbeme> scribenick: ben_thatmustbeme
16:01:29 <cwebber2> ack cwebber2
16:01:35 <cwebber2> ack cwebber
16:02:02 <ben_thatmustbeme> cwebber2: at least from activitypub's standpoint, we support http urls
16:02:16 <ben_thatmustbeme> http urls work great for single user
16:02:22 <ben_thatmustbeme> what is the debate we are haivng
16:02:37 <ben_thatmustbeme> we aren't going to replace webfinger any time soon
16:02:43 <ben_thatmustbeme> we have a route for single user sites
16:02:48 <ben_thatmustbeme> sandro: we don't
16:03:18 <ben_thatmustbeme> a single user can't talk ... lets imaging mastodon implements AP to the spec, and aaronpk supports activitypub
16:03:36 <ben_thatmustbeme> i'm in the mastodon instance, how to i refer to him, how does it look
16:03:56 <cwebber2> q?
16:04:04 <ben_thatmustbeme> cwebber2: if mastodon can support http uris in addition to webfinger, then they wouldn't
16:04:13 <ben_thatmustbeme> s/wouldn't/would
16:04:35 <ben_thatmustbeme> sandro: i don't think nightpool would want to support that, nor would the mastodon community
16:04:50 <ben_thatmustbeme> nightpool: i don't know what Gargron's thinking on this would be
16:04:59 <ben_thatmustbeme> .. i don't think he's considering moving away from webfinger
16:05:07 <cwebber2> ack puckipedia
16:05:35 <ben_thatmustbeme> puckipedia: another thing is that if you allow just a uri as a mention, and you have single user websites, what would be the difference between mentioning me vs my website
16:05:53 <ben_thatmustbeme> ... allowing uri addressing but prefixing it with an @ would be the best solution with that
16:06:32 <ben_thatmustbeme> cwebber2: in the case of https://puckipedia.com, you'd do conneg to pull down the the cotent of the actor vs
16:06:51 <ben_thatmustbeme> sandro: are you saying you'd have to have a different URL for himself vs his blog
16:07:23 <ben_thatmustbeme> sandro: i think a profile url is different from a blog url
16:07:44 <ben_thatmustbeme> cwebber2: saranix brought up the acct schema
16:07:50 <ben_thatmustbeme> s/schema/scheme
16:07:50 <nightpool> q+ to talk about "publically resolvable"
16:07:53 <ben_thatmustbeme> q+
16:07:53 <cwebber2> q?
16:07:55 <tantek> (and even then, just a couple of implementations are insufficient to prove "easily" :) )
16:08:31 <ben_thatmustbeme> sandro: it seems like one quesiton to figure out on the sooner side, is mastodon and other members of the fediverse willing to move to support some kind of non-webfinger ids
16:08:34 <cwebber2> ack nightpool
16:08:34 <Zakim> nightpool, you wanted to talk about "publically resolvable"
16:08:41 <ben_thatmustbeme> if yes, we can do that, if no, we need to figure out some other kind of solution
16:09:30 <ben_thatmustbeme> nightpool: one of the problems in the spec is that every ID must be resolvable, there is no reference as to what that means, is acct:// publicly resolvable?
16:09:47 <ben_thatmustbeme> someone brought up an issue on github of supporting non-iana urls
16:09:59 <ben_thatmustbeme> you can't resolve those if you aren't on openDNS
16:10:09 <cwebber2> q?
16:10:09 <ben_thatmustbeme> we need some kind of clarification behind that
16:10:36 <saranix> I think webfinger itself references an rfc for coming up with the acct: scheme
16:10:37 <ben_thatmustbeme> cwebber2: i think there is no where you are going to be able to resolve an open dns if you don't know what it is
16:11:12 <ben_thatmustbeme> we have not specified what schemes are not usable
16:11:24 <cwebber2> ack ben_thatmustbeme
16:11:27 <cwebber2> scribenick: cwebber2
16:11:41 <nightpool> s/non-iana/non-icann/
16:12:11 <nightpool> s/openDNS/openNIC/
16:12:20 <cwebber2> ben_thatmustbeme: I want to talk about what sandro raised, I wanted to see what it would be like to support non-webfinger uris... pretty nobody was in favor of supporting just https://ben.thatmustbe.me/ but it was pointed out that you could just leave off the user and itw ould work, and it would be at-prefixed, but it would refer to a domain
16:12:22 <Loqi> Ben Roberts
16:12:29 <cwebber2> saranix: so with the https:// or without?
16:13:01 <nightpool> openNIC was the project I was referring to
16:13:04 <cwebber2> ben_thatmustbeme: without, just @ben.thatmustbe.me which I think is a reasonable solution because it's clearly identifying a user but making it clear that it's a domain user rather than a localized one
16:13:04 <saranix> cwebber2: ??
16:13:21 <cwebber2> s/saranix:/sandro:
16:13:41 <cwebber2> q?
16:13:49 <ben_thatmustbeme> i actually have to leave anyway
16:14:10 <nightpool> dots vs no-dots seems like a very fragile solution
16:14:16 <ben_thatmustbeme> +1 to wrapping up
16:14:33 <cwebber2> ben_thatmustbeme++
16:14:33 <Loqi> ben_thatmustbeme has 76 karma in this channel (235 overall)
16:14:34 <nightpool> ben_thatmustbeme++
16:14:34 <Loqi> ben_thatmustbeme has 77 karma in this channel (236 overall)
16:14:41 <cwebber2> trackbot, end meeting
16:14:41 <trackbot> Zakim, list attendees
16:14:41 <Zakim> As of this point the attendees have been cwebber, puckipedia, Gargron, ben_thatmustbeme, (at, least, part, of, meeting), jaywink, nightpool
16:14:49 <trackbot> RRSAgent, please draft minutes
16:14:49 <RRSAgent> I have made the request to generate http://www.w3.org/2017/06/21-social-minutes.html trackbot
16:14:50 <trackbot> RRSAgent, bye
16:14:50 <RRSAgent> I see no action items
16:14:51 <saranix> is it bad to force the posting site to do discovery on the mentioned url to determine whether it is profile or stream?