Social Web Incubator Community Group Teleconference

21 Jun 2017

Attendees

Present: cwebber, puckipedia, Gargron, ben_thatmustbeme, jaywink, nightpool, sandro
Regrets Chair: cwebber2
Scribe: cwebber2, ben_thatmustbeme

<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"?

Gargron: the goal would be to have it not change Mastodon at all, just change the representation underneath

cwebber2: that means you wouldn't really have it in mastodon.

<cwebber2> jaywink, a boolean might work

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.
... it might not be necessary for content warnings

cwebber2: if mastodon isn't going to use it, then it may be the case that leaving it in summary makes sense

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

<cwebber2> jaywink, want to present+?

cwebber2: we talked about that in the WG

<jaywink> (thought I did, maybe there can't be other text on the line ;))

<zatnosk> Hello, I'm zatnosk@manowar.social on mastodon. Listening in as interested person :)

<cwebber2> https://github.com/w3c/activitypub/issues/231

<Loqi> [cwebber] #231 "Sensitive Media" tag

Zakim: who is here?

<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

<jaywink> sorry :(

cwebber2: i would be okay it not being a tag, and being a boolean property attached to the object

<jaywink> welcome zatnosk :)

Gargron: if we are just encoding Mastodon information 1-to-1

then yes, that would work

but i think it might make sense on the document

even if mastodon doesn't use that, maybe someone else will, like if one image is sensative, but the others aren't

cwebber2: if we move to bool prop, there is nothing stopping it from being on the sub objects

<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)

cwebber2: i suppose the reason was we didn't have time and tags was simpler
... but the GW was just extended, so maybe thats ok

puckipedia: i think the boolean would be nice

cwebber2: lets actually capture this as a resolution

<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)

<Loqi> [cwebber] #231 "Sensitive Media" tag

<cwebber2> +1

<Gargron> +1

<puckipedia> +1

<jaywink> +1

<saranix> -1

+0 as i don't know all the details of it

cwebber2: we have a minus 1 from saranix

<cwebber2> saranix, we're not talking about Content Warnings at this point btw

<cwebber2> saranix, specifically about supporting sensitive as a separate boolean, as opposed to having an "official" sensitive/nsfw type tag

Gargron: saranix isn't on the call, so maybe missed some context, its not content warning, but just sensative

<saranix> In my protocol, both content warnings and "sensitive" are handled by a special tag taxonomy

<saranix> ... the same tag taxonomy

<saranix> ... for both

<nightpool> hey, sorry all, just woke up

<cwebber2> nightpool, hey welcome :)

cwebber2: lets just continue, as i'm not sure thats resolved then

<cwebber2> https://github.com/swicg/general/issues/6

<Loqi> [Gargron] #6 Hashtag representation

formatting of tags

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

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

<nightpool> fuck

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
... the possibilities are to use http ids and use fragments

<cwebber2> https://tagnamespace.example#foo

cwebber2: its possible to use ostatus tags

Gargron: Mastodon doesn't use the groups parts of ostatus

<saranix> +1 uri "https://tagnamespace.example#foo"

cwebber2: i think those would work well as mentions
... is the difference between having things that don't have uri vs do

Gargron: yes

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

like gps coords then fragment for the bike at that location

<tantek> of course no tags have ever worked that way in practice on the web

<tantek> e.g. rel=tag tags worked with the last segment of a URL, not #

<tantek> similarly, WordPress categories

<tantek> etc.

so this works in that sense, but ...((??)

Gargron: how about just using the same one for the public collection, then just tacking on the hashtag at the end of htat

cwebber2: you risk people throwing in things the refer to real activitystreams properties

<tantek> I'm opposed to using such URLs for anything persistent since fragments are only interpreted on clients

cwebber2: i think it would need its own seperate base url

<Zakim> nightpool, you wanted to talk about ids

<tantek> I think it's fundamentally bad design

<tantek> and frankly, not what the web has evolved to use

nightpool: saying a hashtag doesn't have an ID doesn't really ring true to me,

every hashtag i've seen links to something

<cwebber2> welcome sandro

cwebber2: are you talking about how servers often have a collection

nightpool: they always seem to link to one location

<tantek> e.g. https://twitter.com/hashtag/socialweb

Gargron: its just a keyword, you may filter that by local only or all known posts, but its just a slice of everything

nightpool: that just means we need to standardize the names better, instead we should have a type that has a specific name field

cwebber2: we have that

nightpool: but the way to specify that its actually...

cwebber2: you end up with blank nodes which go to np-complete type problems

nightpool: it specifies which instance that hash tag comes from, which i think is useful

Gargron: you don't have different hashtags you just have one

<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?

nightpool: suppose its like a group

Gargron: they aren't groups, you would need to have a way to get a hashtag to a certain server

cwebber2: i suggest we use the queue as we have a lot of people now

to put this is prospective, where should it point, do we point to some abstract place, or per instance

<nightpool> tantek: something we discussed this week was ways that JSON=LD specifies for resolving fragment identifiers

lets say we have a federated situation, suppose on each our instances we both tag our #food

do you expect to see your own server's local knowledge, or do you assume you will see only the remote server's

nightpool: i think that depends on the situation

sometimes you want to see only those for an account, sometimes all globally

i think the best is for like federated and local timeline

<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.

you have these resources that are fused into local resourse

cwebber2: any other thoughts on that?

<saranix> I think as far as the spec goes, there should be a specified url (taxonomy) for global tags

Gargron: mastodon does turn all hashtags into a local link, leaving your instance to another place, is bad user experience

a lot of mastodon is built on 'we fetch all the data that we need'

<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"

cwebber2: does it have the sense that we are transforming the global in to the local?

<zatnosk> I need to leave now. It was nice to follow along :)

Gargron: on one hand yes, we do transform the global into the local

<cwebber2> thanks for coming zatnosk :)

<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.

Gargron: the way mastodon works, you only load what you need, a small instance can exist because it only gets what it needs

i am against having anything fully global that puts that extra weight on small instances

cwebber2: if we wanted to be able to distinguish both, we have id and url

we could point the id at the global version and the URL at the global version

<ben_thatmustbeme> that sounds really odd

<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.

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

its going to be redundant to use those other fields for me

Gargron: the only thing we need ids for is the metadata

<jaywink> +1 Gargron I would do the same even if tag had an url - it's kinda irrelevant to building local presentation

nightpool: id on't think the issue is how we represent it, its that we don't have tags in our ontology at all

so a hashtag type is the way to solve it

Gargron: i agree completely

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

<cwebber2> PROPOSED: Add a Tag type (to capture the most common type of tags, and distinguish from Mention/etc)

<cwebber2> +1

puckipedia: i already experiemented with a tag type as i needed it

<nightpool> +1

<jaywink> +1

<puckipedia> +1

+1 seems pretty reasonable

<jaywink> tags are the butter of social media <3

puckipedia++ for citing implementation experience

<Loqi> puckipedia has 2 karma

RESOLUTION: Add a Tag type (to capture the most common type of tags, and distinguish from Mention/etc)

<Gargron> +1

<jaywink> even linkedin has hashtags these days which was a shock to me

webfinger

cwebber2: we did agree that webfinger was important to resolve within the scope of AP
... we have yet to answer how webfinger fits in

ben_thatmustbeme: for me the concern has been to replace it with an improvement

cwebber2: its not going to disappear soon

i know many projects rely on it

sites like mastodon and gnusocial and diaspora still use it

<Zakim> nightpool, you wanted to talk about userless actors

cwebber2: we need to give some sort of compatability route for them

nightpool: mastodon has had some problems with webfinger, (using external services)

<cwebber2> ben_thatmustbeme raised concerns about the difficulty of adopting webfinger

<cwebber2> and the problems for people on single-user sites, etc

nightpool: having actors that are a whole domain is such a niche market

<ben_thatmustbeme> nightpool i would HIGHLY disagree with that

<saranix> +1 https://github.com/w3c/activitypub/issues/194#issuecomment-294930878

<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.

<Loqi> ##...

<cwebber2> scribenick: cwebber2

<ben_thatmustbeme> nightpool: i would say if we have a simpler protocol that doesn't support userless domains we should look at the simpler

puckipedia: I do think that user domains could include subdomains, such as user.mastodon.example, and that may be simpler for some people

<ben_thatmustbeme> puckipedia: the same could be done via subdomains

<ben_thatmustbeme> sandro: this covers a lot of existing sites that aren't social

<ben_thatmustbeme> ... i'd like to see them involved

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

<ben_thatmustbeme> right now there is no computer readable method to do that

<ben_thatmustbeme> ... i think its more than that

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

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

<nightpool> hosts are allowed to not have periods also

sandro: the presence of a period should tell you the difference

ben_thatmustbeme: webfinger allows periods

sandro: gmail allows periods but they're ignored

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

<ben_thatmustbeme> scribenick: ben_thatmustbeme

cwebber2: at least from activitypub's standpoint, we support http urls

http urls work great for single user

what is the debate we are haivng

we aren't going to replace webfinger any time soon

we have a route for single user sites

sandro: we don't

a single user can't talk ... lets imaging mastodon implements AP to the spec, and aaronpk supports activitypub

i'm in the mastodon instance, how to i refer to him, how does it look

cwebber2: if mastodon can support http uris in addition to webfinger, then they would

sandro: i don't think nightpool would want to support that, nor would the mastodon community

nightpool: i don't know what Gargron's thinking on this would be
... i don't think he's considering moving away from webfinger

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
... allowing uri addressing but prefixing it with an @ would be the best solution with that

cwebber2: in the case of https://puckipedia.com, you'd do conneg to pull down the the cotent of the actor vs

sandro: are you saying you'd have to have a different URL for himself vs his blog
... i think a profile url is different from a blog url

cwebber2: saranix brought up the acct scheme

<tantek> (and even then, just a couple of implementations are insufficient to prove "easily" :) )

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

<Zakim> nightpool, you wanted to talk about "publically resolvable"

if yes, we can do that, if no, we need to figure out some other kind of solution

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?

someone brought up an issue on github of supporting non-icann urls

you can't resolve those if you aren't on openNIC

we need some kind of clarification behind that

<saranix> I think webfinger itself references an rfc for coming up with the acct: scheme

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

we have not specified what schemes are not usable

<cwebber2> scribenick: 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

<Loqi> Ben Roberts

sandro: so with the https:// or without?

<nightpool> openNIC was the project I was referring to

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

<saranix> cwebber2: ??

<ben_thatmustbeme> i actually have to leave anyway

<nightpool> dots vs no-dots seems like a very fragile solution

<ben_thatmustbeme> +1 to wrapping up

ben_thatmustbeme++

<Loqi> ben_thatmustbeme has 76 karma in this channel (235 overall)

<nightpool> ben_thatmustbeme++

<Loqi> ben_thatmustbeme has 77 karma in this channel (236 overall)

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

Add a Tag type (to capture the most common type of tags, and distinguish from Mention/etc)

SocialCG/2017-06-21/minutes