Conversation
Notices
-
@simsa0 If user X doesn't have a subscriber at instance A, then X's posts won't appear in TL and convo views on A
-
@simsa0 and sorry for late reply. I don't have time ATM and am not able to read the threads your mentioned. I hope I understood the question
-
@simsa0 guessed #reason: when I post a dent, my instance looks at my subscribers list & sends the dent #only to the respective instances
-
@mmn @simsa0 Suggestion:when $user posts a dent,their instance should send the dent to every known instance,not just to instances of subbers
-
@mcscx @simsa0 Why would a remote instance, knowing only of User A on my server, accept a message from User B? Imho it only increases CPU and bandwidth usage. Another word for sending messages which have not been requested is: spam.
-
I agree. One thing that would be enormously useful, though, is if the server on which a conversation or…
-
@lnxw48 parent retrieval sounds as if unknown replies will remain unknown until (and if at all) a known user has replied
-
@zash good idea
-
@mmn perhaps there could be a per instance flag "this instance wants to receive dents by broadcast transmissions"
-
@mcscx @zash I believe @manuel@lamatriz.org has started working on this. It is probably the most proper solution which requires least hacks.
-
@mmn @mcscx @zash @manuel@lamatriz.org Yes! we are working on this. We want to make able subscriptions to a conversation feeds but not form panoptican approach, it means, we want to subscribe them for show them in other applications, in our case, a plugin we are developing for wordpress !wpgnusocial We are not trying to resolve what someones are calling «missing dents» or «federation issues»
There is not «missing dents» because you have not request them by subscription to the person that published it. Without people connections there is not conversations but monitoring or spam
-
@simsa01 If both authors are subscribed to, both authors' notices will be shown. If they are just "known", that doesn't mean anything and there is no subscription link setup and no reason why I'd want to host a bunch of crap this "known" author writes which I have expressed no interest in (and am not a direct recipient of).
The "remote retrieval" (i.e. fetching a missing "parent notice" retroactively) or making a conversation-subscription is how this should be solved. The latter also means one could _unsubscribe_ from a conversation (which would be impossible if nodes just gladly accepted unrelated notices).
-
@simsa0 In the latest GNU social, conversations are stitched together assuming proper conversation metadata (URI) is provided. This metadata is _not_ provided with StatusNet (which makes up totally new conversation URIs when receiving notices and then continues to distribute this incorrect URI when pushing out replies on the topic).
-
@simsa0 I think everyone are capable of understanding pros, cons and peculiar behaviour duribg the development phase. It would be bad if "newbs" actively avoided software which admits to being actively improved.
-
@simsa0 You're welcome to give us all your money so we can improve these things. But it will still take time after that. Until then, I think it's a good thing that the network is used, bugs are reported (can't report bugs without actually testing!) and users don't have to stick with proprietary spy-networks to do what they do here.
And people do come here. People do stay. And things are improving. Too bad we can't improve at the same rate as commercial companies. Maybe we should start selling user data, advertise and hire a couple of full-time programmers?
-
@lnxw48 They _are_ desirable features in the technical _specification_ of the protocol. There is absolutely no reason for anyone to have an implementation which accepts spam.
The way to solve this - which is being worked on - is to have another type of subscription (i.e. conversation thread, which is already an RSS/Atom feed - just no mechanism to subscribe). Not an ugly hack (randomly accepting new, unasked for notices) which diverts from any spec out there.
Noone is saying that missing notices are a feature.
-
@lnxw48 If you're thinking about the Las Indias(?) article, I didn't interpret it quite like that. More that it's not always a bad thing - in many circumstances it is actually a desired feature not to receive notices (which would bump up the thread in current implementations) from _every_ party who gets involved in the conversation.
I think everyone agrees that there should be a convenient method to still import the missing notices just in case - but they should perhaps not be pushed by default. Such distribution in a decentralized world can cause performance issues and reminds me of the #tent.io protocol which was heavily criticised for being extremely unscalable.
-
I don't think this attitude is getting anyone anywhere. I prefer constructive criticism and helpful attitudes. You've just made it to my block list.
-
Also, you're welcome to say I don't do anything to the commit timeline here: https://openhub.net/p/gnusocial/commits/summary
I bet it will tell you that work is being done, but without guaranteed time nothing it is hard to perform miracles. (I don't get money for this, so I can't devote time away from my job or too much free time). Thankfully, there are also other contributors who I greatly appreciate the work of.
@mcscx@quitter.se
MMN-o ✅⃠
LÆMEUR (@SDF)
Manuel Ortega
All Chirp! content and data are available under the