Skip to content
  • 11 Votes
    61 Posts
    537 Views
    scott@authorship.studioS
    Having a separate thread property may be useful. One possible use case would be where threads or posts are labelled or categorized or placed in a list, and this is exposed as a context.In that case, the thread and the context would be different. cc: @Evan Prodromou @Sean Tilley @julian @Darius Kazemi
  • 4 Votes
    7 Posts
    136 Views
    damon@social.wedistribute.orgD
    @julian Yes, it was me. Thank you, I figured it was the one by Mr. Mike, thank you
  • 4 Votes
    3 Posts
    217 Views
    julianJ
    @[email protected] thank you!
  • 3 Votes
    3 Posts
    172 Views
    julianJ
    ForumWG meeting in ~1 hour N.B. We are deferring discussion on 1b12 vs 400e as @[email protected] is currently mid-flight, but will continue to discuss resolvable context, backfill, and syncing. There will be time for an open floor to discuss new topics, so if you have any ideas that may benefit the forum and threaded discussions sector of the fediverse, you are welcome to bring them up! Meeting Link
  • 8 Votes
    12 Posts
    532 Views
    silverpill@mitra.socialS
    @julian @alex-mehr @trwnh>There's no guarantee that a collection would present items in chronological vs. reverse chronological order — are you checking the timestamps and reversing as needed?The ordering can be specified by some property of Collection>Wouldn't you need to paginage through the entire collection anyway?The client will fetch pages until it finds an item that has already been processed.> I think that informs why I set up topic synchronization in this manner, and why my idea of context collections contain only objects; to me, activities don't really mean much at all.I'd prefer context to be a collection of objects too, as long as there's a way to retrieve activity history.Activity-based sync seems more natural to me. I think ActivityPub can be better understood not as a protocol for social networking, but as a distributed database where nodes sync datasets by sending messages over the network. Messages are activities, datasets are collections. When I send a Follow activity and your server responds with an Accept, followers and following collections are updated on both sides (or their equivalents if you don't store activities and collections). More generally, any activity delivery can be viewed as a synchronization of outbox collection.I think such change of perspective can greatly improve DX and provide a solid foundation for further protocol extensions
  • 3 Votes
    3 Posts
    132 Views
    antonio5609@socialhub.activitypub.rocksA
    Hi,Thanks for sharing this information.
  • 21 Votes
    23 Posts
    1k Views
    julianJ
    @eeeee don't engage, some people will always be unhappy unless they get everything for free.
  • 3 Votes
    21 Posts
    510 Views
    trwnh@socialhub.activitypub.rocksT
    I might not be communicating clearly either, but it’s a consistency thing. The intended usage I’m advocating for is to “make it an actor” by giving it an inbox and outbox, but also to go further and make self-managing collections that are attributed to themselves and Add objects into themselves. You can make the outbox private but you probably don’t want to. I don’t really see why to leave it out unless you were really adamant that the collections wouldn’t be actors. And if you go as far as I’m proposing with self-managing collections, then those are more clearly actors because they will be the actor of the Add activity. But also, you don’t have to go that far to just stick an outbox on it.
  • 0 Votes
    11 Posts
    314 Views
    stevebate@socialhub.activitypub.rocksS
    The AS2 Recommendation defines actors as "entities capable of carrying out an Activity" and (for the Applicationactor property) "[describing] one or more entities that either performed or are expected to perform the activity". One can infer that any Object referenced or Link'ed to by the actor property of an Activity type is an actor that "carried out (or performed) the activity".The ActivityPub Recommendation added additional requirements for an actor to have inbox and outbox endpoints. (However, the inverse isn't necessarily true. An object with an inbox and outbox endpoint may or may not be an AP actor.)From my perspective this means there are AS2 actors and there are AP actors. The former have no inbox/outbox requirement. The AP actors are a constrained variant of AS2 actors. An application can have both kind of actors. Obviously, the AS2-only actors cannot communicate using AP inboxes, but they may still be useful, in general, for modeling "entities capable of carrying out an Activity".I'm not making any claims about well this would interoperate given how the existing AP implementations have evolved. Most current applications are hard-coded to a very restricted subset of AS2 types and often make actor-related assumptions that are not part of the AS2/AP Recommendations.In practice, beyond the 5 core actor "types" in AS2, identifying actor and extended actor types seems to me to be very application-specific.
  • 1 Votes
    15 Posts
    444 Views
    julianJ
    I've also added FEP 1b12 announces for additional activities: Create Update Like Undo(Like) Delete Confirming that at least Discourse accepted the Announce(Like(Note)) and parsed it correctly.
  • 7 Votes
    4 Posts
    426 Views
    angus@socialhub.activitypub.rocksA
    Hey guys, looking forwarding to seeing you at the meeting today. We have a new video-call url:https://meet.jit.si/ap-forum-wgWe're getting the link updated on our SocialCG event too.
  • 2 Votes
    18 Posts
    760 Views
    julianJ
    Thanks @[email protected]! That's good feedback and it's really exciting to know that there exist implementors out there whose default is not Note. I think at this point a real-time discussion at the next ForumWG re: the distinction between Article vs. Note would be beneficial. It'd be a continuation of the discussion we had last month. It's clear there are varied opinions on it, but as intimated by others, this might not actually be a problem that has technical solution.
  • 7 Votes
    30 Posts
    1k Views
    angus@socialhub.activitypub.rocksA
    I think the answer to that has to be that you have to take whatever context is associated with the object you're sent as canonical. Otherwise we'll always be second-guessing. The context on the object of the first object in whatever collection you resolve could also be "wrong". Yes, practically speaking, this may lead to errors in certain cases, however I think that's better than making the context overly relative.**edit I guess in this case, practically speaking, you'd follow up with the implementer of whatever platform is being used to resolve the context you initially got and ask them to fix their issue
  • 7 Votes
    4 Posts
    689 Views
    trwnh@mastodon.socialT
    @julian to clarify: this is mostly about "canonical" identifiers vs. aliases. there is generally one canonical identifier for the conversation collection, and this is what should be used as the value of `context`. this could get a bit complicated but there are potential ways to coordinate replication between equivalent conversation collections, probably involving mutual following/follower relationship, plus some indicator of aliases like `alsoKnownAs` or some other extension property.
  • 14 Votes
    43 Posts
    2k Views
    silverpill@mitra.socialS
    @grishka @mikedev>The originating server may not know who is part of the group and who is not, and therefore it can't enforce privacy by requiring a signed fetch.In Friendica, group participants are represented by private followers collection, which can be retrieved using signed fetch:https://socialhub.activitypub.rocks/ap/object/781ebb23f1080082071d0c156543eb5fSo I don't see any fundamental difference between FEP-400e and FEP-1b12. The authentication issue, however, is quite important, because without FEP-8b32 the group either doesn't scale or can impersonate anyone.@julian
  • 6 Votes
    6 Posts
    597 Views
    luceos@socialhub.activitypub.rocksL
    trwnh: Topics can be split In addition to splitting topics, topics or their posts can also be merged into another topic. The UX for this is quite variable; sometimes entire topics can be merged into another, sometimes a certain range of posts within a topic (post 5 .. 10 from 15 posts), and sometimes a selection (post 5 and 10 from 15 posts or just a singular item post 5 from 15 posts). trwnh: Topics exist in a category For #Flarum topics can also not exist in a Category (we call them tags and that extension is optional, like all of our extensions). Even when using a Category, once the Category is deleted, we do not hard delete any topics contained within but unlink them, making them less visible but still existing within the Forum. Regardless, to us, Topics CAN exist in a category, it's not required. trwnh: Users can be followed for posts and topics Users can be messaged directly This sounds as if this is a given, I don't think it's guaranteed in every Forum software. But if can implies optional, then