I invite ALL federation developers to hop into #social on irc.w3.org for conversations around the social Web. It's where a few discussions on #ActivityPub discussions occur.
I know that we have http://socialhub.network/ for this as well and I encourage the devs to use these places in conjunction to this one for conversations for historical and open discussion reasons.
@emacsen I mentioned WebFingerId not as a part of WebFinger protocol, but only as an artificially created identifier, helping to figure out the same actors via old-style (Twitter-like...) client APIs (which don't provide globally unique identifiers of actors (users...)). As we're currently are figuring out, how to use #ActivityPub C2S protocol in the real world :-) I see that WebfingerId isn't really needed in ActivityPub API: Actor's profile has enough information to know both username and hostname of an actor (what constitutes WebFingerId). I think that you will be interested to read our discussion on this here: https://github.com/andstatus/andstatus/issues/499
I made the simplest implementation of #ActivityPub C2S protocol in #AndStatus, allowing me to log into pleroma.site, read home timeline and get other user's info (i.e. read the Actor's profile based on his "id"). But I've got an error response from pleroma.site server on an attempt to send a Note, so I created another bug report in pleroma issues tracker: https://git.pleroma.social/pleroma/pleroma/issues/650
@lanodan It's OK for #Mastodon and #Pleroma to use in their UI "summary" property only. Especially taking into account that Mastodon actually doesn't have Title/Subject of a "toot" but "CW" only (Content Warning) that fits into semantics of #ActivityPub's "summary" better than into "name". Above decision shouldn't influence the "name" property, one of basic properties of #ActivityPub vocabulary.
Regarding current usage: Pump.io uses both "name" and "summary" properties since its creation in 2013, and they live together without problems.
Discussion of the #ActivityPub Note's "name" property usage and it's processing by Pleroma. Main attention is on the Client to Server interactions that are being implemented in #AndStatus.
I feel that we mixing two different use cases here:
1. An ActivityPub property, to which a Note's Subject/Title is placed, when entered via Pleroma web UI. I understood about this point.
2. Delivery / sending to other servers a Note, which came from a client application or from another server and which has the "name" property. I assume that if incoming Note has the "name" property, Pleroma doesn't delete that property, but sends it to recipients with the same value. ?!
@rysiek Maybe it's the right time to start building (or completing implementation of) #ActivityPub compatible client to server API and not waste time on improvements of Mastodon's custom API ?! @dfeyer @kaniini @maryjane
@kaniini Thank you, after several attempts I figured out the correct full URL for the "whoami" API endpoint: https://pleroma.site/users/AndStatus/inbox - and I got JSON response. Will parse it and return to You to move further, if you don't mind :-)
However, this URL, looking like an actor's inbox, is conceptually incorrect for the "whoami" call as even #ActivityPub spec says: "The inbox is discovered through the inbox property of an actor's profile". This is why the "whoami" call should be the same for every user, and not the "inbox" of a concrete user/actor. I think :-)
This is "whoami" call where the authenticated Actor receives his/her profile information, including URLs of endpoints!
The demo I'm working on at this hackathon is for a secure way of hosting content so that if your instance goes down, your content can survive, and if your content becomes popular, the whole network can help balance the work of hosting it. #activitypub#wizardstower2019
#AndStatus Android client is ready for integration/developer's testing of the "client to server" #ActivityPub protocol. I created an alpha build of AndStatus for server developer, which allows to use AndStatus as a manual Server API testing tool. In order to move forward, past authorisation step, I need an account on a server that successfully authenticates/authorises a User. Servers that I'm aware of, didn't automate/implement the Client registration/User authorisation steps yet...
@dpwiz I didn't send HTML-formatted notes to GNU Social via #AndStatus yet :-) Looks like I need to either find a way to tell a server that a note ("notice") has text/html media type, or revert to the plain text sending for GNU Social. BTW text/html is the default media type for #ActivityPub content.
@autogestion A month or two ago I visited the https://test.activitypub.rocks site and at last found out, which exactly features are REQUIRED for a client app to formally declare its support of #ActivityPub. I've added "Client discovers the URL of a user's outbox from their profile" already, working on other features. What's most important is that internal data model of #AndStatus is already compatible with #ActivityPub, I hope :-) The only hard part to implement is compatible OAUTH (AndStatus supports two variants of OAuth, but it looks like I will need the third for ActivityPub...) After completion of the REQUIRED features I will create the new "ActivityPub" Social Network Type (in addition to the three existing) and will start actual testing... Unfortunately, I don't see any working _real_ (not a toy) server with Client to Server layer support, where I could register as a user and test my client app ;-( ?!
@aldobelus I know about problems with #notifications, please read my reply to you 5 days ago about my own investigation of possible causes, including about "there is nothing new". Unfortunately, due to the Twitter-like approach in a server to client communication taken by GNU Social many years ago and even by Mastodon recently, notes and activities that look the same for a human eye, are represented as different by each server. This is the main cause of users' confusions seeing notifications about the same activities. Hoping that the networks will eventually implement #ActivityPub "client to server layer" spec that resolves this deficiency, I plan to improve Notifications in #AndStatus even in the presence of such unavoidable duplicates... And another note: Looking for Notifications improvements, please make sure that you have AndStatus v.43.02 installed, see https://github.com/andstatus/andstatus/issues/456