-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include informative section suggesting how WebFinger users can migrate towards ActivityPub adoption? #194
Comments
This sounds useful. I'd also be happy to put it in SWP as well or instead. |
@cwebber Is there any reason why the reverse (AP-to-WF) lookup can't just pass the ActivityPub URI as the Example:WF-to-AP: |
Some of this was covered during the original WebFinger discussion (#20). Suggestion: If the user enters an acct URI:
Servers SHOULD return one of the acct: URI or the AS2 URI in the For advertising a WebFinger-esque handle in a profile:
The exact rels to use is an interesting question. rel=self is defined by Atom; rel=me is from XFN. I'm more unsure about rel=me than rel=self for this. Examples:
Servers probably MUST NOT trust any rel=me URIs with different host parts without verification for obvious reasons. |
(Oh, and for user entered IDs which aren't valid URIs: Suggest normalization as per OpenID Connect Discovery) |
We talked about this on the call; it doesn't seem like this needs to go into the standard proper, since there seem to be good ways to infer the right behavior. (If somehow a property is really needed, it could be an extension, but it isn't looking like it is to make this work.) However, we should have a good wiki page for this and try to encourage consensus around the groups coming from WebFinger directions on what the right approach is. I'm not sure what page would be the best to use, whether it should be under the Socialwg namespace or something else (the upcoming community group?) |
I like the idea of using webfinger to find out the information in both directions btw! |
New wiki page about this: https://www.w3.org/wiki/ActivityPub_and_WebFinger |
Any idea what the |
@evanminto rel=self seems like it may be right? #204 seems kinda relevant to that convo. BTW I'm tagging this with "postponed" but not closing it yet, mainly because good conversation still seems to be happening. |
RFC4287 (Atom) says
If we interpret it as then the relationship seems appropriate - I am looking up the person "foo@example.com" and their description is here --
|
One thing to consider regarding Webfinger is the syntax and aesthetics: Something I heard a lot from new users, during the early days of Mastodon, was that they hated that handles had 2 @s. It doesn't look very good and also makes it strangely similar to email. I can give you " Another issue that came up is that if you share your WebFinger handle on twitter or other social media, it tags the domain as a user. Every single time someone says "Follow me I'm WebFinger compatibility is useful for compatibility with other federated systems, so it may be that the @name@domain.tld syntax is here to stay. If it is possible to use an alternative syntax, such as This is a relatively minor comment though. Like I said, if double @ syntax is how it's gotta be then I think the world will manage. I just figured since we're building a protocol, now would be the time to bring this up so we don't end up with another situation like we did earlier where when users brought up issues with the syntax all we could say was "well, it's already the protocol, too late to change it" |
We had a huge talk about this in the irc channel the other day! The current
trend in the micropub space is "well, just use URIs", but I find that MUCH
less intuitive then the double @ syntax. Plus, it privileges people that
can find/host their own domains, which is a barrier to adoption.
I find that the leading @ actually distinguishes it pretty well from email?
I'd be interested in exploring other "handle-like" syntaxes though.
…On Wed, May 10, 2017 at 2:40 PM Shel Raphen ***@***.***> wrote:
One thing to consider regarding Webfinger is the syntax and aesthetics:
Something I heard a lot from new users, during the early days of Mastodon,
was that they hated that handles had 2 @s <https://github.com/s>. It
doesn't look very good and also makes it strangely similar to email. I can
give you ***@***.***_" and that's pretty clear it's Twitter. "
@***@***.***" looks like an email (which makes sense since
it's WebFinger) but that makes it seem like I'm telling you to email me,
not to follow me. So I tell people "Follow me on Mastodon" but like, then I
have a friend who is on GNU Social; they're not following me on Mastodon,
they're follow me on GNU Social. As the number of federated softwares using
the same protocol increase, it becomes increasingly difficult for the
layman to understand that something is the same network. "Follow me on the
OStatus Fediverse" is very not catchy and "ActivityPub-Compliant Social
Media" is... even less so.
Another issue that came up is that if you share your WebFinger handle on
twitter or other social media, it tags the domain as a user. Every single
time someone says "Follow me I'm @***@***.***" it tags the
user @mastodon on twitter. We actually got complaints from twitter users
saying that we were harassing them and requested we change the second @ to
something else so people would stop tagging them if they happened to have a
common domain as their username ***@***.*** @awoo @toot @pouet etc. are
all domain domains with various .tlds). Unfortunately there was nothing
that could be done because OStatus uses WebFinger and WebFinger uses 2 @s.
"You'll have to get twitter to change this because there's nothing we can
do at this point, the protocol is already written."
WebFinger compatibility is useful for compatibility with other federated
systems, so it may be that the @***@***.*** syntax is here to stay.
If it is possible to use an alternative syntax, such as @user:domain.tld
@user>domain.tld @user.domain.tld @user\domain.tld or @user!domain.tld
(really anything intuitive) it would resolve some issues and satisfy the
end-user's desire for *aesthetics* as well as make it very apparent from
syntax that it is not an email.
This is a relatively minor comment though. Like I said, if double @ syntax
is how it's gotta be then I think the world will manage. I just figured
since we're building a protocol, now would be the time to bring this up so
we don't end up with another situation like we did earlier where when users
brought up issues with the syntax all we could say was "well, it's already
the protocol, too late to change it"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#194 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORV4fDxWL3cL257bFeSZnvLcvx-anzks5r4gSvgaJpZM4M_xhm>
.
|
An example of a URI in this case would be "https://nightpool.club", or "
https://example.org/nightpool" being used as actors
…On Wed, May 10, 2017 at 2:53 PM Evan G ***@***.***> wrote:
We had a huge talk about this in the irc channel the other day! The
current trend in the micropub space is "well, just use URIs", but I find
that MUCH less intuitive then the double @ syntax. Plus, it privileges
people that can find/host their own domains, which is a barrier to adoption.
I find that the leading @ actually distinguishes it pretty well from
email? I'd be interested in exploring other "handle-like" syntaxes though.
On Wed, May 10, 2017 at 2:40 PM Shel Raphen ***@***.***>
wrote:
> One thing to consider regarding Webfinger is the syntax and aesthetics:
>
> Something I heard a lot from new users, during the early days of
> Mastodon, was that they hated that handles had 2 @s
> <https://github.com/s>. It doesn't look very good and also makes it
> strangely similar to email. I can give you ***@***.***_" and that's pretty
> clear it's Twitter. ***@***.***@icosahedron.website" looks like an email
> (which makes sense since it's WebFinger) but that makes it seem like I'm
> telling you to email me, not to follow me. So I tell people "Follow me on
> Mastodon" but like, then I have a friend who is on GNU Social; they're not
> following me on Mastodon, they're follow me on GNU Social. As the number of
> federated softwares using the same protocol increase, it becomes
> increasingly difficult for the layman to understand that something is the
> same network. "Follow me on the OStatus Fediverse" is very not catchy and
> "ActivityPub-Compliant Social Media" is... even less so.
>
> Another issue that came up is that if you share your WebFinger handle on
> twitter or other social media, it tags the domain as a user. Every single
> time someone says "Follow me I'm @***@***.***" it tags the
> user @mastodon on twitter. We actually got complaints from twitter users
> saying that we were harassing them and requested we change the second @ to
> something else so people would stop tagging them if they happened to have a
> common domain as their username ***@***.*** @awoo @toot @pouet etc. are
> all domain domains with various .tlds). Unfortunately there was nothing
> that could be done because OStatus uses WebFinger and WebFinger uses 2 @s.
> "You'll have to get twitter to change this because there's nothing we can
> do at this point, the protocol is already written."
>
> WebFinger compatibility is useful for compatibility with other federated
> systems, so it may be that the @***@***.*** syntax is here to stay.
> If it is possible to use an alternative syntax, such as @user:domain.tld
> @user>domain.tld @user.domain.tld @user\domain.tld or @user!domain.tld
> (really anything intuitive) it would resolve some issues and satisfy the
> end-user's desire for *aesthetics* as well as make it very apparent from
> syntax that it is not an email.
>
> This is a relatively minor comment though. Like I said, if double @
> syntax is how it's gotta be then I think the world will manage. I just
> figured since we're building a protocol, now would be the time to bring
> this up so we don't end up with another situation like we did earlier where
> when users brought up issues with the syntax all we could say was "well,
> it's already the protocol, too late to change it"
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#194 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAORV4fDxWL3cL257bFeSZnvLcvx-anzks5r4gSvgaJpZM4M_xhm>
> .
>
|
Something of a third option is @domain.name This seems important for any business or entity that's actually known by a domain name. If you're United Airlines, you don't want to be tooting as @united@united.com or @pr@united.com or something. It'd be much cleaner, perhaps clean enough to be tolerable, to be @united.com. I don't think the user-faces sides of the protocol are really frozen, but it would take significant effort to get everyone moving in the same direction. I'd think a reasonable path forward is suggest UIs support all three @user@host.domain, @domain.name, and URLs. Maybe allow the @ before URLs. Maybe allow URLs to be abbreviated, dropping the 'https://'. Let people use any of these for mentions & "follow me at", and make sure they all work. When I use any while composing a post or searching, the system should dereference and confirm what I'm talking about. Then time will tell what wins out. |
Note that the leading @ isn't really a part of any protocol syntax; it's more convention, originally established by Twitter and now popularised elsewhere (e.g. Facebook uses a leading @ to indicate you're tagging a person, Github does the same, etc; but in the Facebook case the @ isn't displayed and there's no reason an implementation couldn't do similar) The OpenID connect canonicalization algorithm I mentioned above handles "user@domain.name", "domain.name", "domain.name/foo" and similar formats (I'm omitting the leading @ here - you might use it as an introducer, but it's kind of unnecessary depending upon your system's UI). Running the algorithm will canonicalize those three into The first is an acct: URI, so you'd need to do WebFinger discovery. For the others, you can "follow your nose" (Request with Accept: activitystreams and, if that fails, scrape for http Link headers or HTML tags with rel=alternative type=activitystreams) A client could easily take the entered URI and replace it with a display name and link if it wanted. |
That sounds great to me (under the circumstance). So the question may be how we gather consensus around doing this canonicalization, and wf if necessary. Do we want some kind of W3C Note explaining how to do this, or make it part of AP, or ... what? |
@oshepherd Do you know how the OIDC standards process works? How stable is that spec? Is there a test suite, implementation report, etc? |
Lots of federated systems have historically used WebFinger. We should provide them a guide on how to move forward with using ActivityPub. This came up in the thread about supporting ActivityPub on Mastodon and is surely a question any OStatus implementation will encounter, as well as users of the old Pump API.
I've laid out a possible rout about how to possibly interact with WebFinger accounts while still using https:// type uri scheme for actor ids and @wilkie has also written up useful thoughts, including how Webfinger accounts may be used with tags.
Is this a good idea to include? If we do so we should make sure to work with existing WebFinger users.
The text was updated successfully, but these errors were encountered: