Conversation
Notices
-
For those who've noticed the long pause to be "posting" a message in the Qvitter modal, I have to. I know what causes it, but I'm not sure it's easily mitigated, because it has to do with how the system manages federating posts. It'll probably wait to be properly fixed until I redo how the queue handlers are, well, handled.
TLDR: When you make a post, a copy of it is sent out to all the servers we federate with. This is over 60 servers for this instance, last time I checked, and grows weekly. Each copy of the notice is sent out in series. What this means is it sends out the local notice in the database, then the one to quitter.se, then the one to Potato Knishesposter.club, etc so forth, as it goes down the list. They're done one at a time, in the order they appear in the hubsub table.
So essentially, you're waiting for each notice to be sent and acknowledged, before that modal disappears. This is why it takes so long.-
When I look at the queue handlers, I'll probably be writing an Apache style workers based queue server to be the default postActiv handler. This will greatly increase the performance of the server in a variety of ways by making tasks run in parallel.
The old GNU social OpprotunisticQM will remain available as a fall-back.
Not sure about the shell script daemon, because I have never been able to make it work reliably. -
@maiyannah Two things:
1. Can you set another PUSH-server? That should solve it.
2. Why does qvitter even do it like that...-
@lambadalambda
1. You can use a STOMP server. But it has some errors that I've been slowly working out on my development server. When I've got those fixed I'll push the patch to postActiv nightly, and probably use that.
2. Essentially because of the way the GNU social API is designed. A lot of our current problems come down to "well Twitter does it that way and so the API is designed that way to be compatible with Twitter".
While I can understand not wanting to break compatibility since this allows us to use 3rd Party Twitter apps on Android and iOS, such as AndStatus, it's been getting more and more tempting to just break that compatability for the sake of having a program that would, frankly, run a lot better, or at least in a more sane manner.-
@lambadalambda At the same time I just sigh and realize that then the main difference people are going to see between GNU social and postActiv is that you can't use those apps with postActiv, so they wouldn't migrate, even if I did things much better on postActiv.
People have an inertia about apps they use that they are familiar with that is very difficult to overcome. It's why so many people are still on Twitter when GNU social, postActiv, and Mastodon exist, after all. -
@maiyannah I meant a third party PUSH server like superfeedr. It's nice that GS includes its own stomp server, but makes things kinda slow. For the second thing, I don't really buy that argument. My client doesn't wait for the server response and there's no modal to block the screen.
-
@lambadalambda You can use an external STOMP server is what I mean by saying that, sorry if I was not clear in my wording.
-
@lambadalambda see "stomp_server" et all under queue in CONFIGURE, for eg here's postActiv's (basically the same as GNU socials atm, just markdown formatted for readability)
- https://git.gnu.io/maiyannah/postActiv/blob/nightly/CONFIGURE.md-
@maiyannah I don't mean the stomp server, just the pubsubhubbub server. Afaik, @gargron uses superfeeder in mastodon.
-
@lambadalambda Perhaps I should explain.
In GNU social as stands presently, you have three different means to federate notices to other servers:
OpprotunisticQM,
CLI Script Daemons,
or
an external STOMP server
By default, for compatibility with the most number of systems, GNU social uses OpprotunisticQM. OpprotunisticQM functions by processing a certain amount of outstanding queue items every time PHP processes a page on the instance. So every time someone visits a page on the site, OpprotunisticQM processes some of the outstaning queue claims. A queue claim can be any Activity object, be it a Notice, a Favourite, a Subscription, etc. This is compatible with any setup that runs PHP, but is comparably quite slow.-
@lambadalambda The script daemons run through the CLI in a background process to constantly process the GNU social activity queue. This means that they're constantly being looked at, and not piling up. It trades a neccesary overhead for the spikes you can get presently with OpprotunisticQM. The problem I - and other - server operators have had, is they segfault pretty regularly. I remember Moonman saying he had the same troubles as I. So they're unreliable.
A STOMP server is probably actually the best answer that GNU social presently has, because you can offload all of the message processing workload to a server entirely seperate from the database altogether. This can be any server that you have credentials for that supports the Streaming Text-Oriented Messaging Protocol. The thing I'm working out with it right now is retries, since they're neccesary to even over federation issues such as with RDN.
-
-
-
-
-
@lambadalambda It's waiting for an API response because that's what the Twitter app does (and Twitter is doing on web though the actual website is more complicated than that).
But yeah, if you disregard the response and go back to the main page regardless, you avoid that issue entirely. I wonder if there's any reason to wait for it? Qvitter doesn't seem to have any way to determine the post hasn't sent and display an error, as far as I am aware, which would be the one reason I'd wait for an ack if I was programming it. Maybe I'll see if I can't just take it out.-
@maiyannah Everytime I look into the Qvitter source to change a 'little' thing, it turns out to be hard to impossible...
-
@lambadalambda This is part of why I figure to myself it'll probably be something I properly fix after I have the templates code in place and don't need Qvitter anymore ... because a lot of things are going to feel a lot easier then >.>
-
@maiyannah Don't give up...
-
@lambadalambda Eh, meh, I kind of regret saying that way because I recognize that Hannes work is a hack on top of a hack on top of a hack to make this house of cards that is a custom GNU social theme work to begin with, but the fact that so much trouble goes into changing things with this is precisely why I think it'll be a good thing when I get a proper theme system in.
-
-
-
-
-
@maiyannah@community.highlandarrow.com I think GNU Social SHOULD change its client API to allow fully use advantages of its federation. Please read this discussion on a new API: https://github.com/andstatus/andstatus/issues/419
@lambadalambda-
@andstatus @thefaico If there's anything specific you'd like added, feel free to add an issue on the postActiv repo and I can take a look and put it in PA at least: https://git.gnu.io/maiyannah/postActiv
-
@andstatus @thefaico Just to be clear, I don't mean to be shoving this off to you or something, but one thing I get very much from your discussion with Gargron is that you have a very good handle already on what you would consider ideal for requests. So what I would suggest (and like to see if you have the time and inclination) is maybe an outline of what you thing the ideal responses are for a given use case/lookup, and I can tailor the new API to your needs as well as a few other requests I have received.
-
@maiyannah I think it would be overkill for us to invent some completely new API. From this position I see two main ways of current API improvement, and we can go both ways, implementing them separately:
1. Improvement of "Twitter” compatible API. The change that I propose is easily described and it may seem not that deep, but for some reason even @gargron, who, as I thought, is building a new API now, took a long pause on it:
in ALL API calls get rid of ALL "local IDs" (IDs of people, messages etc...), replacing them with URIs, which are the same for the same identifiable things (i.e. for the same objects) in all GNU Social instances. This requirement is easy to implement, if an URI:
1.1. Contains unique hostname of the GNU Social instance.
1.2. Contains type of the identifiable object,
e.g. ”acct:andstatus@loadaverage.org” - for an "account" ("person"), like in Pump.io.
The hard part of this change is that it requires changes in request parameters and (or) in data returned of all API calls. I mean we should go through all API calls and replace all local IDs with URIs, which I suspect not always exist in GNU Social for some objects...
2. Complete and document an API, based on Activity Streams and JSON format. As @mmn wrote me, Activity Streams + JSON are already implemented in GNU Social. But absence of documentation and working examples is a blocker here. This could be the second step of changes...
@lambadalambda @pennyfortheguy @mcscx-
@andstatus @thefaico @lambadalambda
TBQH it's probably easier for me to rewrite the json as stuff whole cloth than try to modify what's there already, for a variety of reasons.
-
-
-
@gargron btw, apart from TwitterAPI !GNUsocial has another client connection method called #AtomPub http://qttr.at/1jgr
-
-
-
-
