I'm reading the OCAPPUB paper by @cwebber in preparation of the #APConf. It's very interesting, and I highly recommend #ActivityPub implementors to read and share it.
@rmbl Oh, I see that I was confused a bit about terminology. The "Group" notion in #ActivityPub is about a group of Actors (people etc.), but we are talking here about a named "Collection" of notes/activities. But actually GNU Social calls such collections "Groups" :-) I'm creating descriptions and comparisons of Groups/Lists notions in different types of social networks, supported by #AndStatus, here: https://github.com/andstatus/andstatus/issues/248#issuecomment-219826572
No, I don't use IRC. That way of communication is in another Universe for me :-)
@rmbl Sometimes I need the same, and I also feel that it is inconvenient to keep "unread" all notifications in order not to forget one of them. Recently I started implementation of Group/Lists support in #AndStatus. And I see that creation of some personal "ToDo" group and adding any note/ activity to that group could help in such cases. Unfortunately AFAIK only #ActivityPub supports such actions, meaning that such custom groups of notes could be automatically synced between User's devices or even shared... Moreover, each "Social network" in #AndStatus logically should have its own group... So it seems that I will start from some device-local groups (like tags...) that can be easily viewed... @fedilab
@moonman There are two dimentions in the support of different protocols of Social networks, which I'm facing during development : 1. Implementation of different API calls and parsing responses of every API of every supported protocol. I cope with this problem simply by implementing only some of available APIs (features)... 2. Trying to adapt internal data/actions model so that it could fit into conceptual differencies of different systems. This is a lot more time consuming and difficult to do right. In #AndStatus we started ten years ago with Twitter-like model. For the last two years I'm gradually converting it into #ActivityPub based model...
@colegota In short: Notifications section in #AndStatus settings lists some other things; not timelines. Longer answer: "Unread notifications" timeline includes activities: "create(post) note", "announce (retweet/repost/reblog) note", etc. which were recognized by AndStatus app as belonging to at least one of checked "Notification event types". No matter how the activity was received for some of them (e.g. for mentions) but one-to-one for others: "Home timeline" notification corresponds to the Home API timeline for all Twitter-like APIs (i.e. Twitter, GNU Social and Mastodon) and Inbox API timeline for #ActivityPub client to server API. Meaning of some AndStatus Timelines are changing over time. E.g. even for me it's unclear yet, if "Unread notifications" timeline notifies "the account" (as it was implemented quite long ago) or it should rather notify My Actor who happens to be linked to an account on some server... I clarify this for myself also, and make corresponding changes in the app...
I think ActivityPub is a great start to #decentralize/#redecentralize, but getting deep into collaborating on the same works is going to require more extension. forgefed has high potential in to advance our ability to work together.
@FuzboleroXV I think that #NomadicIdentity is primarily about moving your identity _between_ accounts and corresponding hosts/providers. Being able to access several "nomadic identities" via one account is a byproduct for me, not so important. Main point here though is separation between a User (person or organization...), an Account and the "identity" (called an Actor in #ActivityPub).
@z428 As you may see from the discussion it the GitHub issue, the first and maybe the most undefined step in the #ActivityPub#C2S specification is authentication and whoami (account verification/discovery) steps. We agreed on concrete steps and endpoints with pleroma.site developer, but the same probably won't work out of the box with other systems. Anyway, I'm open to collaboration and aim at creation of really unified API, compliant with ActivityPub C2S.