@weekinfediverse elk (A nimble Mastodon web client) I would be really happy if the category “Clients” would get subcategories. Elk is a Mastodon client and therefore does not speak fediverse protocol. Or am I wrong with my opinion ?
@pfefferle@darnell I use uuids for the ObjectIds (actor id). I had also toyed with the idea of using the Oauth2 UserId, but decided against it. I might want to allow the actor to log in with 2 different Oauth2 providers at some point.
However, this makes debugging and troubleshooting hell ;-)
@sl007@pfefferle@evan if tools don't work without webfinger, it doesn't help much not to support webfinger. it doesn't matter whether webfinger is part of Activitypub or not.
In his presentation for berlin, @evan talked about activities regarding HTTP signature and webfinger. Are there any documents on this that I don't know about?
@pfefferle@evan@julian Client developers are very welcome. that's not my focus at all. and it would be very good to have a client developer who has a different perspective. I would start with “Notes” anyway, as this is the easiest to test with other servers. next steps, however, are stabilization, webfinger feditests, following..., http signature.
@pfefferle Wäre schön, wenn es eine deutsch sprechende community geben würde, die sich regelmässig online trifft. Das würde mich wesentlich weniger stressen ;-)
Question: Hi there, i would like to order the ActivityPub by Evan Prodromou ISBN: 9781098169466 as print version. Is this possible ?
Answer: Hi Fred, Thanks for contacting us. Unfortunately, this title has been canceled and can't be ordered. Please let me know if you have any questions.
@evan@steve I take a very critical view of this! 1. John writes a note “Russia has started the war” 2. mike likes john's note 3. John changes the note “Ukraine has started the war” 4. now Mike likes a note that he may never see and that he even thinks is wrong.
This is my understanding of the AP update process at the moment
@steve If there is exactly one object, then John no longer has access to the object after the update, or how else should I solve the access management. It is also possible that the object has changes after the update that John should not see.
@steve but there is no update for me either. An object is always an ordered collection and the subject points to the latest entry. I will document this when I get the chance. Because if, for example, “CC” is changed, then I see inconsistencies. Version1 : Max and John are in CC Version 2 : Max is in CC ...
@steve “That's why one Create/Note can be referenced by many inboxes” Theoretically, I agree with you. But that's up to the implementation. I'm not yet sure how I'm going to solve this. But at the moment, each actor has its own RDF “database”. That gives me a more secure feeling with SPARQL queries and export or migration are much easier to implement. At the moment I also have a memory for the public actor. How I solve this with the shared inbox remains to be seen.
@pfefferle@deadsuperhero Das ist übel, wird sich aber nicht vermeiden lassen. Ich hatte mal erwähnt, dass ich gerne eine Instanz fragen möchte, welche Typen sie denn versteht/akzeptiert, dann könnte "mein" Server reagieren und entsprechend übersetzen. Theoretisch würde es reichen, wenn ich Erfahre Mastondon in Version x.y, der Rest könnte statisch sein. Eine weitere Idee wäre eine "zentrale" (natürlich nicht, aber das geht noch nicht in meinen Kopf) zu haben, die Mapping Infos bereitstellt ;-)