Notices tagged with activitypub, page 2
-
@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.
?!
https://git.pleroma.social/pleroma/pleroma/issues/635 -
@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!
?! -
@kaniini I'm testing client to server #ActivityPub implementation of #Pleroma So far I cannot even complete user authorization step and get the authenticated Actor's endpoints (whoami / verify credentials...) at #Pleroma , because I don't know URL of the API point, see https://github.com/andstatus/andstatus/issues/499#issuecomment-457942709
Could anybody help me?
@mmn -
#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...
More details and discussion are here: https://github.com/andstatus/andstatus/issues/499 -
@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 -
Note - Client to server #ActivityPub layer for #Pump.io ?!
@alex@pump.strugee.net @evan@identi.ca Hello pals!
Looking at the Pump.io's GitHub site https://github.com/pump-io/pump.io I see some discussions regarding #ActivityPub support, but I couldn't figure out if you are implementing client to server layer of #ActivityPub ?!
If yes, what's the status of this work?
I want to make #AndStatus Android app an ActivityPub client, but I need at least one server that supports this in order to test my implementation, naturally :-)
--
yvolk@identi.ca
URL: https://identi.ca/yvolk/note/ab2wuiDPTYOQBjupeSmYRA -
Note - Client to server #ActivityPub layer for #Pump.io ?!
@alex@pump.strugee.net @evan@identi.ca Hello pals!
Looking at the Pump.io's GitHub site https://github.com/pump-io/pump.io I see some discussions regarding #ActivityPub support, but I couldn't figure out if you are implementing client to server layer of #ActivityPub ?!
If yes, what's the status of this work?
I want to make #AndStatus Android app an ActivityPub client, but I need at least one server that supports this in order to test my implementation, naturally :-)
--
yvolk@identi.ca
URL: https://identi.ca/yvolk/note/ab2wuiDPTYOQBjupeSmYRA -
@dansup Any progress on #ActivityPub client to server implementation for #GnuSocial?
Maybe you know that someone else is doing this? -
BTW: I can guarantee that #Friendica will include #ActivityPub by the end of the year, since this comment here is posted via AP with Friendica ????
The code needs cleanup and yet not everything is coded, but it is working well so far. -
BTW: I can guarantee that #Friendica will include #ActivityPub by the end of the year, since this comment here is posted via AP with Friendica ????
The code needs cleanup and yet not everything is coded, but it is working well so far. -
Still working on sending the `Accept` activity back after receiving a `Follow` on @write_as. If I don't sign the request Mastodon rejects it.
I'm reading that there's no official authentication method in the #ActivityPub spec, but that HTTP Signatures should be enough, but also that I might need Linked Data Signatures for things that'll get passed around (like posts). Will see.
I'm now looking at #Plume and Mastodon's code to figure out what data to send. #federation
-
Still working on sending the `Accept` activity back after receiving a `Follow` on @write_as. If I don't sign the request Mastodon rejects it.
I'm reading that there's no official authentication method in the #ActivityPub spec, but that HTTP Signatures should be enough, but also that I might need Linked Data Signatures for things that'll get passed around (like posts). Will see.
I'm now looking at #Plume and Mastodon's code to figure out what data to send. #federation
-
@gdorn ...We need to adopt some syntax to tell the application that substring search should be used. #ActivityPub doesn't mention any query syntax. So in order to filter by a part of URL I think that Twitter's "premium" :-) syntax could be used, e.g.:
contains:loadaverage.org
or even:
contains://loadaverage.org/
- in order to avoid matching with longer domain names
(see https://developer.twitter.com/en/docs/tweets/rules-and-filtering/overview/premium-operators.html )
?! -
@gdorn ...We need to adopt some syntax to tell the application that substring search should be used. #ActivityPub doesn't mention any query syntax. So in order to filter by a part of URL I think that Twitter's "premium" :-) syntax could be used, e.g.:
contains:loadaverage.org
or even:
contains://loadaverage.org/
- in order to avoid matching with longer domain names
(see https://developer.twitter.com/en/docs/tweets/rules-and-filtering/overview/premium-operators.html )
?! -
@xosem vamos por partes...
Para mi la (presunta) comunidad de !gnusocial la formamos todas. Tanto las personas que desarrollan y mantienen como las que lo utilizamos.
La respuesta rápida a la pregunta de dónde están las personas que desarrollan (y mantienen) es el canal #social de Freenode en el IRC. Que tiene su puente a la sala xmpp:gnusocial@conference.bka.li
No obstante, como es más o menos conocido ni la persona que lo desarrollaba ni la que lo mantiene/mantenía disponen de tiempo y/o fuerzas en este momento para continuarlo.
Es el problema de que tengamos tan pocas personas dedicadas a trabajar para tantas otras.
En el lado positivo, este verano @up201705417 y @dansup van a implementar #ActivityPub en #gnusocial.
Y a mi lo que más me esperanza del proyecto no es la posibilidad de ampliar la federación, que también, sino el hecho de que para ello se tendrán que desbloquear algunas cosas y puede que sea el principio de algo más a largo plazo. -
@xosem vamos por partes...
Para mi la (presunta) comunidad de !gnusocial la formamos todas. Tanto las personas que desarrollan y mantienen como las que lo utilizamos.
La respuesta rápida a la pregunta de dónde están las personas que desarrollan (y mantienen) es el canal #social de Freenode en el IRC. Que tiene su puente a la sala xmpp:gnusocial@conference.bka.li
No obstante, como es más o menos conocido ni la persona que lo desarrollaba ni la que lo mantiene/mantenía disponen de tiempo y/o fuerzas en este momento para continuarlo.
Es el problema de que tengamos tan pocas personas dedicadas a trabajar para tantas otras.
En el lado positivo, este verano @up201705417 y @dansup van a implementar #ActivityPub en #gnusocial.
Y a mi lo que más me esperanza del proyecto no es la posibilidad de ampliar la federación, que también, sino el hecho de que para ello se tendrán que desbloquear algunas cosas y puede que sea el principio de algo más a largo plazo. -
@lnxw37d2 Yes, having competition is always good :-)
I hope that #GNUSocial will get #ActivityPub server to user protocol, at last. Thus opening a door for young and ambitious developers eager to change the world.
Regarding #AndStatus performance, it's already noticeably better in v.39. And Timelines open even faster in v.40, which I plan to post for Beta testing later today...
@lnxw48@fresh.federati.net @mike -
@maiyannah Actually recent #AndStatus development was focused on aligning internal data model with #ActivityPub specification.
Regarding recently introduced (regression) problems with GNU Social - I am simply unaware of such cases. If you have such problems, please file bugs here: https://github.com/andstatus/andstatus/issues
@mcnalu -
Exciting news (thanks to @wakest):
Welcome Misskey!
https://github.com/syuilo/misskey
A sophisticated microblogging platform, and part of #Fediverse.
#ActivityPub compatible - so you can follow #Misskey users right now. Polls, server info, dark mode, emoji reactions, recommended users, and much more! Join and contribute :love: -
Exciting news (thanks to @wakest):
Welcome Misskey!
https://github.com/syuilo/misskey
A sophisticated microblogging platform, and part of #Fediverse.
#ActivityPub compatible - so you can follow #Misskey users right now. Polls, server info, dark mode, emoji reactions, recommended users, and much more! Join and contribute :love: -
movim.au and #libervia are federated social network clients using the #XMPP standard instead of #OStatus or #ActivityPub
-
@ma1uta Actually this is limitation of the "Twitter-compatible API" in #Friendica that causes such unexpected behavior. #AndStatus doesn't have separate API for Friendica and and its developer, with whom I collaborated, deliberately decided to adapt Friendica to the same client API that GNU Social uses and not to create a custom one. I hope Friendica will create #ActivityPub client-to-server protocol as GNU Social plans to do this summer...
@paulelms @balancer -
@lightweight also, have you thought about #ActivityPub compatible comments, so I can post a comment there, and have it appear here?
-
... the avatar service could actually become federated in practice, not just in potential (is #Libravatar obsoleted by #ActivityPub though?)
-
@dansup Do you mean implementation of Client-to-Server part of #ActivityPub also?
-
mcscx
gnusocial
, paulfree14
, throgh
, z428
@throgh an der Unterstützung von #ActivityPub für !GNUsocial wird weiter gearbeitet: http://qttr.at/23bd @paulfree14 @z428
