AndStatus@Mastodon @AndStatus@mastodon.social

@dwaltiz I fixed probable cause of the "lost draft" problem, that you encountered, in #AndStatus v.47.11 (released yesterday). A draft could be lost (unsent and invisible in a timeline) in a case there was another draft saved earlier by the same account.
Now different drafts don't interfere with each other.

@tom79 This is about testing #friendica instance using #ActivityPub Client to Server protocol of #AndStatus https://github.com/andstatus/andstatus/issues/499
The error occurs during client registration.
Actually I don't even know if Friendica supports this at all:-)
@z428

@tom79 I think user's confusion is caused by widely advertised "#ActivityPub support", which in reality for almost all servers (except for #Pleroma, as I know) means server to server communication only. Pleroma is the first Social Network that implemented at least minimal set of features, allowing ActivityPub Client applications to connect to it.
@z428 @thefaico

@dwaltiz Funny proposal :-)
I think it's much easier to fix the problem that you encountered (I suspect it's about UI/#UX) yet even _you_ didn't find time to file the issue properly, trying to reproduce it, describing steps to reproduce the issue and attaching screenshots. Just this post that doesn't help to make the app better, unfortunately :-(
Yes, there may be "steps back" (developers call them "regressions") but they occur exactly because I'm rewriting #AndStatus and rely on community members, who take their time to explain, what went wrong...
So, when you are ready to help, please file the bug here and we will substantially discuss it: https://github.com/andstatus/andstatus/issues?q=is%3Aissue+sort%3Aupdated-desc
Maybe at that stage somebody will join us with concrete help...

One of interesting discussions with a volunteer translator. This time - on usage of "we" in the phrase "We have these settings..." and on posting one's thoughts to the Internet in general https://crowdin.com/translate/andstatus/16/enus-da#1670 (looks like you need an account there to see the discussion...)

#AndStatus v.47.03 "Avatars and Attachments improved" Beta is published, see https://github.com/andstatus/andstatus/issues/456

What's new:
1. When some Actor follows (or stops following) me, show detailed info about that Actor, not about my Actor.
2. If an attached video has a preview image, that image will be shown (currently available for Mastodon only). View image / View media context menu item for remotely accessed media files.
Show a text link to a media file, for which even preview image couldn't be downloaded (instead of no attachment at all as before). #502
3. Don't download attached Video by default. May be changed in Settings -> Attachments -> Download attached video
4. Actor's avatar in their profile is shown with maximum resolution.
5. Fixed: Cannot delete a Note's Title (Name) after it was first saved (even in a draft).
6. Fixed: Default notification sound was heard even if set to Silent in Settings. This was caused by changed rules after starting to target Android 9.
Any Android notification (including Vibration and Sound) should show an icon in Notification Area (Android 9 restriction). https://loadaverage.org/attachment/5061991

@nestort It appears that AndStatus still cannot show a preview of remote media files that it didn't download. Currently only locally downloaded images/video files are shown at attachments and may be viewed. As a result, media files that are larger than configured in "Attachments -> Maximum size of an attachment" are not shown at all.
We need to store locally a preview image (if it is available) and show that image. Or at least show a text link to the media file, for which even preview image couldn't be downloaded.
I created the ticket for the feature https://github.com/andstatus/andstatus/issues/502

@emacsen Oh, I understand now. Regarding following different Actors (located at one or different servers) of the same User/Person in one #ActivityPub network.
The problem is only with Actors ("identities" as you called them) that were originally created mostly because networks didn't communicate with each other, and so one person created duplicating Actors in order to be a part of a larger community.
This is exactly why I worked with #ActivityPub W3C working group to clearly separate notions of a User and of an Actor:
E.g. in a data model of #AndStatus client I created separate entities for a User and for an Actor, allowing one User to be linked to more than one Actor. Currently this feature is used to automatically identify and link actors in different networks, having the same WebFingerId (e.g. on different instances of GNU Social or Mastodon), but it can be extended to link (manually for the start...) e.g. Actors that are known to represent the same Person...

PS: Replying to you from my "personal actor".

@thefaico @eliotberriot @andstatus @trwnh @cwebber

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

Alpha build of AndStatus is attached to this comment: https://github.com/andstatus/andstatus/issues/499#issue-389014088 , source code is available in the repository. https://loadaverage.org/attachment/5020018

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

@andstatus Pleroma/Mastodon WebUI is using the summary field, name has just no place at all in the REST APIs nor in the current world of the fediverse.
And even in a bit different world: Friendica posts with a title are Articles, without they are Notes.

@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.

We could successfully create an account in #AndStatus via #ActivityPub Client to Server API.
Now the time came to parse timelines...
@AndStatus

@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

@colegota I need to look into Notifications another time, after the latest crash fix (that was a one line fix actually). Looks like different "notification channels" are mixed...

Okay, just read about what Mastalab is and you definitely shouldn't be using qvitter API given that some instances (like the one I'm using) don't have that plugin installed.

About getting notifications, I've been using @andstatus and it is very competent in notifying me, so I guess maybe that app developer might be able to provide you with the required guidance. Or you can just look for the bit of code handling that on AndStatus, it is FLOSS :)

@tom79 Notifications in #AndStatus may actually originate from any downloaded note, from any timeline. The application then decides if any given note is deserved to be notified about (according to user's settings...)
I think that the key difference here between AndStatus and #Mastalab is that AndStatus downloads and analyses _all_ timelines in a background beforehand. All timelines are ready for reading even without Internet connection. Mastalab downloads only a small portion thus having less data to think about. And it requires Internet connection when you click on a notification: you will see nothing without Internet.
@up201705417@loadaverage.org I like your words "competent in notifying me", thank you :-)
@lnxw48a1 @colegota https://loadaverage.org/attachment/4987331