@julian diving into the hard problems of building for the Fediverse at #Fedicon, starting with hilariously talking about how those hard problems look like to average users 😅
-
I've been in all three of these scenarios!
-
Delegating search to another party would be great! I'm on a small instance that has not implemented search due to limited time/resources.
-
@ahimsa_pdx @julian many such cases!
-
I'm also very familiar with "Open original page" when certain replies aren't loading, or when images aren't loading.
-
ahimsa_pdx@disabled.social there were actually ten slides
wait for the video clip to come out in a couple days I think! -
@quillmatiq @julian hashtags are part of the text which encourages people to use less hashtags so that they can write more actual text instead.
this also reduces the searchability because people cannot append appropriate hashtags that the original author might have forgotten.if tags were a separate list they could be added to similarly to how we can add emoji to other people's posts and they wouldn't subtract from the space for the actual text.
-
loganer@mastodon.social actually...
> if tags were a separate list
They are, per the protocol. For the same reason I derided mention spamming in my presentation, tags don't need to be in the post body either.
-
@julian but in the interface you still write it in into the same area as the rest of the text and it still counts on the character counter. #AsYouCanSeeHere
-
loganer@mastodon.social correct! We're talking past each other and arguing the same thing. The Mastodon UI needs work
-
@julian and furthermore if I had attached an image of a dog to the post, you could not add the hashtag dog to the post if I had forgotten it.
you would need to comment that it was missing and then I would have to add it.
-
Yes, count me in. I've been working on FEP-3b86 "Activity Intents" that is a "lighter weight" process that doesn't trade tokens with my origin server and relies on my home server to do all the work.
Mike, how does all of this relate to FEP-61cf: "The OpenWebAuth Protocol"? Should we keep it in mind as well?
Each process will have unique strengths and weaknesses, so Julian had proposed looking for a way to support multiple connections at the same time.
-
The way I see it, there are two parts to solving account fragmentation.
- Log in via your handle
- This is the entirety of FEP-61cf: The OpenWebAuth Protocol
- This is the first half of FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API
- In FEP-3b86: Activity Intents, the exercise is left to the reader
- Do something using that handle
- In FEP-61cf: The OpenWebAuth Protocol, this exercise is left to the reader
- This is the second half of FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API
- This is the entirety of FEP-3b86: Activity Intents
So you can see that these three FEPs attempt to solve different parts of the problem, but that doesn't necessarily mean that they conflict. In fact, the "first half" can be done however you want. I think benpate@mastodon.social said that it could literally be as simple as showing a textbox in the UI that says "paste your home server here". No OAuth or jwt hijinks necessary.
It's the second half where we need to come up with a recommendation for how to gracefully degrade between APIs. (instead of progressively enhancing)
fentiger@mastodon.social thanks for reminding me of your FEP. Let's include it in our discussions and work together.
- Log in via your handle
-
@julian @benpate @FenTiger @evan I am still unclear about how to separate the resource server from the authentication server when implementing FEP-d8c2. This is an essential criterion of OAuth2 and enables the use of existing OAuth2 servers. However, I have the feeling that FEP-d8c2 blocks this path.
FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API
Hello! This is a discussion thread for the proposed FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API. Please use this thread to discuss the proposed FEP and any potential problems or improvements that can be addres…
SocialHub (socialhub.activitypub.rocks)
naturzukunft (@naturzukunft@mastodon.social)
@evanprodromou@socialwebfoundation.org Let's find that out https://socialhub.activitypub.rocks/t/fep-d8c2-oauth-2-0-profile-for-the-activitypub-api/3575/38?u=naturzukunft
Mastodon (mastodon.social)
-
naturzukunft@mastodon.social the assumption here is that the authentication server and the resource server are identical.
I know thisismissem@hachyderm.io has thoughts on this because people will want to use third party authentication like FusionAuth.
I don't have an answer for that yet, but I am of the opinion that we proceed with a proof of concept without an answer for now.
-
@benpate @julian I'm not sure OWA is the way forward here; mainly it's a lightweight authentication-only alternative to OAuth, and for FEP-d8c2-style SSO the authorization part - issuing the access_token - is important.
FEP-61cf does describe the "zid" mechanism that can be used to avoid the user having to type their handle in; maybe this will be useful (though it's not without its downsides).
-
@julian @benpate @evan I think FEP-3b86 only really allows for actions that the home server already knows how to carry out; the advantage of FEP-d8c2 is that it allows clients to add functionality of their own; see eg Evan's checkin app, which can post geo-tagged activities even via a server which doesn't natively support them.
-
@julian @thisismissem Currently, this would mean that #rdfpub will not participate in this proof of concept, as https://www.keycloak.org/ does not support FEP-d8c2. I would argue that FEP-d8c2 is not OAuth2 if a server such as keycloak cannot be used.
-
@naturzukunft @julian @benpate @evan They can't be entirely separated because the AS has to know how to dereference the client_id.
The Client ID Metadata Documents draft RFC will make it possible to do this without relying on non-OAuth standards on the AS side. I doubt there are many servers that support it right now, though (but I think Rauthy has some degree of support for this).
-
-
@naturzukunft @julian @benpate @evan Well, it's always been intended as a toolkit rather than as a "plug and play" server/client that are automatically compatible with one another.
