@julian not sure which language this is, but isn't there any sort of short-circuiting on `if`?
`if condition1 && condition2` should immediately stop if condition1 is false, leaving condition2 never evaluated
i have approximate knowledge of many things. perpetual student. (nb/ace/they)
xmpp/email: a@trwnh.com
https://trwnh.com
help me live:
- https://donate.stripe.com/4gwcPCaMpcQ19RC4gg
- https://liberapay.com/trwnh
notes:
- my triggers are moths and glitter
- i have all notifs except mentions turned off, so please interact if you wanna be friends! i literally will not notice otherwise
- dm me if i did something wrong, so i can improve
- purest person on fedi, do not lewd in my presence
@julian not sure which language this is, but isn't there any sort of short-circuiting on `if`?
`if condition1 && condition2` should immediately stop if condition1 is false, leaving condition2 never evaluated
@julian the taxonomist in me screams, for i do not know what i am looking at (and people refuse to describe it properly)
@julian mods can delete a thread, right? this doesn't necessarily delete all posts in the thread, but they do become orphans
controversial protocol goals for a more conversational fedi:
- you should be able to create explicit threads instead of a loose reply tree
- you should be able to follow a thread without following any people or groups
- you should be able to delete a thread and have all posts declaring that thread as a context be marked as orphans to be garbage-collected
- you should be able to participate in a thread remotely, like commenting on github issues via email
@mikedev more generally, there are a lot of conceptual issues with AS2 Collection in both data model and protocol. it seems especially problematic to say that a conversation/thread *is* a Collection, because a Collection can be anything -- someone's followers, a conversation, a photo album, an audience, a feed, a task list, and so on. imo this is a fundamental error in information modeling. a Collection ought to represent a set, not myriad other entities that might *have* a Collection.
@mikedev i think this is all protocol stuff, and the real madness is claiming we have a single protocol called "activitypub" that everyone can implement the same way
rather, a protocol is the sum total of everything needed to communicate, negotiated between parties. fundamentally this question is about whether you store activities as resources, or just consume them as RPC. but ideally the conversation/thread should be agnostic to this, and it shouldn't be bound to any particular representation.
@mikedev I wonder, what do you think about having conversations represented by a specific Conversation object? Basically, saying a conversation *has* a collection of posts, rather than saying that a conversation *is* a collection of posts.
- Conversation.posts = Collection of Objects
- Conversation.outbox = Collection of Activities
- Post.context = Conversation
where "Post" is loosely an Object that has content
@julian @silverpill the third point which is more contentious:
- deleting a context implies all objects included in it are now orphans and can be garbage-collected (deleted, updated, moved, whatever)
@julian @silverpill right, it's a bidirectional link that should be verified both ways ideally. so you have an object claiming to be included, but you also ideally have a reverse claim of inclusion
i think you can mostly get away with doing something like:
- if context is present and it has a canonical collection, you can browse it directly. ignore the original object
- if someone declares your context and you become aware of it somehow, you can optionally add it to the canonical collection
@silverpill @julian @pfefferle @jesseplusplus @harmonicarichard the context SHOULD be copied if you want to participate in the same context, but the owner MAY Add whatever they want to an arbitrary Collection
context-unaware impls aren't prevented from participating but this will lead to a degraded experience if you're not careful. likely you would start with some graph source, filter for context, then optionally crawl replies for anything missing or otherwise optionally reverse query inReplyTo