Advancing Ticket Auth to more interoperable implementations

[capjamesg]

@dshanske and I are going to be working on TicketAuth implementations. From the draft specification:

Ticket Auth is an extension to IndieAuth that enables a publisher to send authorization, known as a ticket, that can be redeemed for an access token. This allows both solicited and unsolicited invitations to fetch restricted resources.

If anyone is interested in independently implementing the spec along with us, please respond here!

[melvincarvalho]

Roughly how many Daily Active Users (DAUs) does TicketAuth have?

[capjamesg]

@melvincarvalho This spec is an incubation. The specification states "This specification is still in early development." Please see the linked wiki page for a list of implementations.

Generally, DAUs are not a helpful metric to consider for the CG. More DAUs doesn't mean a specification is any more or less important than any others. The question to ask instead is "what problem does this help us solve in the social web?" In this case, we are trying to explore what site-to-site private posts look like, a topic not addressed in existing work.

[melvincarvalho]

Does it have any users at all?

[capjamesg]

Please read the wiki page. The spec has multiple interoperable implementations, but there is a lot of work to do before it could be considered a draft.

[melvincarvalho]

If you are proposing this to the group, please give a ball park user count of the work.

Reading the spec it has historically had a user count of 5, is that correct?

[dshanske]

@dshanske and I are going to be working on TicketAuth implementations. From the draft specification:

Ticket Auth is an extension to IndieAuth that enables a publisher to send authorization, known as a ticket, that can be redeemed for an access token. This allows both solicited and unsolicited invitations to fetch restricted resources.

If anyone is interested in independently implementing the spec along with us, please respond here!

I'm happy to help Allowing people to access private content on a website has been discussed almost every time I've gotten together with people interested in social interaction since 2014.

I've followed multiple proposals over the years and none have gained traction due complexity. I started contributing to Ticket Auth efforts because it has the possibility to be simple enough to gain wide adoption.

[aaronpk]

Asking how many daily active users a new spec has is not productive. Remember that ActivityPub had no daily active users when it started.

[melvincarvalho]

Remember that ActivityPub had no daily active users when it started.

Thanks for the reminder. Starting with no active users tends to be the exception, rather than the norm. Developers often like to get a feel of adoption first, before diving into an implementation. But I think you've mostly answered that question, so thanks.

[dshanske]

Remember that ActivityPub had no daily active users when it started.

Thanks for the reminder. Starting with no active users tends to be the exception, rather than the norm. Developers often like to get a feel of adoption first, before diving into an implementation. But I think you've mostly answered that question, so thanks.

Perhaps I'm missing something, but if you have to start out with a large amount of daily users as a prerequisite, then the only way for your thing to come into existence is magically willing it into being fully formed.

If I understand the mission of this group, it is to "provide space to collaborate and coordinate for implementors who are building on any of the specifications published by the Social Web WG, and related technologies. It is also a place to incubate new proposals which build on or complement the Social Web WG recommendations."(https://www.w3.org/community/socialcg/) .

[bumblefudge]

Well, I think the analogy might be kind of flawed to begin with, because IndieAuth has plenty of users and implementations, and this is just a feature extension to add some AuthZ to indieauth, right? The better analogy might be to a multi-author FEP (or more precisely to the proposed process for the CG turning multi-implemented FEPs into CG Notes) than to a net-new SocialCG spec Note. I see no harm in leaving this issue open to see if others want to implement together and work this up to CG review level?