aboutsummaryrefslogtreecommitdiffstats
path: root/include/notifier.php
Commit message (Collapse)AuthorAgeFilesLines
* fix for forked thread on diasporaredmatrix2015-05-271-11/+0
|
* revert for nowredmatrix2015-05-271-5/+5
|
* Comments need to have some kind of routing instructions.redmatrix2015-05-261-0/+13
|
* disconnectfriendica2015-04-231-7/+15
|
* more work on queue optimisationsfriendica2015-03-091-3/+18
|
* Fix a couple of places where we weren't checking for dead hublocs. Add a ↵friendica2015-02-271-5/+14
| | | | function to mark a hubloc dead.
* syntax - missing argfriendica2015-02-251-1/+1
|
* this may actually fix the deliver loop when deleting existing items. It's ↵friendica2015-02-251-1/+8
| | | | hackish but I don't see any other way out.
* Found the cause of the delete looping, and I can prevent it going forward. ↵friendica2015-02-251-2/+7
| | | | The issue remains what to do about comments which are already in the DB and have ITEM_ORIGIN incorrectly set. We can't exactly reset them because the "original" context has been lost. (Sorry but couldn't resist an insider pun that none of you will be able to follow anyway). Read the comments.
* don't send deleted items upstream - only downstream.friendica2015-02-241-3/+6
|
* send rating information to directoriesfriendica2015-02-021-14/+0
|
* updates to put rating info into the local xlink before sending it to known ↵friendica2015-01-281-0/+10
| | | | directory servers
* include channel clones in PM deliveries (also some whitespace edits)friendica2015-01-081-0/+1
|
* make unique hub filter more robust and straight-forward so it's easier to ↵friendica2014-12-171-7/+25
| | | | understand and debug since it's such a critical piece of the delivery chain
* critical notifier fix to make diaspora delivery work reliably again. If ↵friendica2014-12-171-18/+11
| | | | everything breaks revert or debug.
* PostgreSQL support initial commitHabeas Codice2014-11-131-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were 11 main types of changes: - UPDATE's and DELETE's sometimes had LIMIT 1 at the end of them. This is not only non-compliant but it would certainly not do what whoever wrote it thought it would. It is likely this mistake was just copied from Friendica. All of these instances, the LIMIT 1 was simply removed. - Bitwise operations (and even some non-zero int checks) erroneously rely on MySQL implicit integer-boolean conversion in the WHERE clauses. This is non-compliant (and bad programming practice to boot). Proper explicit boolean conversions were added. New queries should use proper conventions. - MySQL has a different operator for bitwise XOR than postgres. Rather than add yet another dba_ func, I converted them to "& ~" ("AND NOT") when turning off, and "|" ("OR") when turning on. There were no true toggles (XOR). New queries should refrain from using XOR when not necessary. - There are several fields which the schema has marked as NOT NULL, but the inserts don't specify them. The reason this works is because mysql totally ignores the constraint and adds an empty text default automatically. Again, non-compliant, obviously. In these cases a default of empty text was added. - Several statements rely on a non-standard MySQL feature (http://dev.mysql.com/doc/refman/5.5/en/group-by-handling.html). These queries can all be rewritten to be standards compliant. Interestingly enough, the newly rewritten standards compliant queries run a zillion times faster, even on MySQL. - A couple of function/operator name translations were needed (RAND/RANDOM, GROUP_CONCAT/STRING_AGG, UTC_NOW, REGEXP/~, ^/#) -- assist functions added in the dba_ - INTERVALs: postgres requires quotes around the value, mysql requires that there are not quotes around the value -- assist functions added in the dba_ - NULL_DATE's -- Postgres does not allow the invalid date '0000-00-00 00:00:00' (there is no such thing as year 0 or month 0 or day 0). We use '0001-01-01 00:00:00' for postgres. Conversions are handled in Zot/item packets automagically by quoting all dates with dbescdate(). - char(##) specifications in the schema creates fields with blank spaces that aren't trimmed in the code. MySQL apparently treats char(##) as varchar(##), again, non-compliant. Since postgres works better with text fields anyway, this ball of bugs was simply side-stepped by using 'text' datatype for all text fields in the postgres schema. varchar was used in a couple of places where it actually seemed appropriate (size constraint), but without rigorously vetting that all of the PHP code actually validates data, new bugs might come out from under the rug. - postgres doesn't store nul bytes and a few other non-printables in text fields, even when quoted. bytea fields were used when storing binary data (photo.data, attach.data). A new dbescbin() function was added to handle this transparently. - postgres does not support LIMIT #,# syntax. All databases support LIMIT # OFFSET # syntax. Statements were updated to be standard. These changes require corresponding changes in the coding standards. Please review those before adding any code going forward. Still on my TODO list: - remove quotes from non-reserved identifiers and make reserved identifiers use dba func for quoting - Rewrite search queries for better results (both MySQL and Postgres)
* disable request message response until we work through thisfriendica2014-11-011-1/+0
|
* What this checkin does is catch the case where a comment arrived and there's ↵friendica2014-10-301-0/+35
| | | | a missing top-level post to match it with. So we'll send a request back to the sender that you've never seen this thread and please send a fresh copy of the entire conversation to date. We could soon have posts in the matrix from different platforms from days gone by, which have been migrated into the modern world. We'll be polite and not deliver these to everybody. However, if someone comments on one of these antique threads we wouldn't be able to see it in our own matrix because we won't have a copy of the parent post. So this rectifies that situation. Be aware that item deletion may need to change to keep "hard deleted" items indefinitely so that they don't keep coming back. We'll have to null out the important data of the former item to accomplish the deletion aspect.
* d* PM cont.friendica2014-09-231-1/+1
|
* found the suckerfriendica2014-09-221-0/+2
|
* we don't always set HUBLOC_FLAGS_DELETED but we often set hubloc_status = ↵friendica2014-09-211-2/+3
| | | | HUBLOC_OFFLINE instead. Filter this as well from deliveries.
* final piece of the mrjive delivery puzzle, and now we've got most all the ↵friendica2014-09-151-3/+6
| | | | tools to implement mod_hubman
* provide a way to sync locations and get rid of bogus hublocs, now implementedfriendica2014-09-141-0/+27
|
* log why this doesn't get executedfriendica2014-09-121-0/+2
|
* works one way sort of - now to go the other way - which will require fixing ↵friendica2014-08-261-3/+3
| | | | a whole slew of FIXMEs
* houston we have liftofffriendica2014-08-261-1/+1
|
* more diaspora stuff - most of the basic bits are there except queueing and ↵friendica2014-08-251-1/+1
| | | | physical delivery (I'm keeping delivery turned off until some of the bugs are fixed so we don't cause inifinite loops or network meltdowns) - now it's just a matter of going through and methodically finding all the bugs
* sort out some anomaliesfriendica2014-08-251-2/+2
|
* more diaspora heavy liftingfriendica2014-08-251-17/+60
|
* We really can't do this without a hubloc. I was hoping we could, but ↵friendica2014-08-221-1/+1
| | | | notifier is setup to take hublocs, not xchans.
* homepage revisionsfriendica2014-07-061-8/+9
|
* make folks from certain other networks feel more at home herefriendica2014-05-021-0/+8
|
* tag anyonefriendica2014-04-151-17/+3
|
* make sure we can find that functionfriendica2014-04-111-0/+1
|
* we also need a loop breakerfriendica2014-04-111-0/+6
|
* this should improve queue performance dramatically.friendica2014-03-241-2/+4
|
* we don't allow forgeries to be received - save some bandwidth by not ↵friendica2014-03-211-0/+5
| | | | allowing them to be sent. We do have to figure out how some secondary delivery chains are ending up with posts belonging to the original owner instead of the chain owner, but that's for another day.
* try to reduce the number of simulaneous deliveries of the same post when ↵friendica2014-01-221-2/+22
| | | | dealing with owner relays that have more than one channel instance. If things melt down in the next few hours and I'm not available please revert this. I've reviewed a few times and think it's OK, but this part of the delivery code is traditionally touchy.
* this is necessary for any possibility of a federated future.friendica2013-11-211-1/+16
|
* add aid to notifiy table which we may need to supress duplicate notify ↵friendica2013-11-201-4/+8
| | | | | | emails across your channels also try to handle the wretched mess of broken and duplicated hublocs that fred.cepheus.uberspace.de typically reports
* create update record for accounts on directory server itself during profile ↵friendica2013-10-241-1/+1
| | | | changes, re-queue failed directory sync packets, fix account_id index in queue creation, be more selective about updating hubloc_connected (only when we're talking to the associated site). But we still need a way to flag dead accounts and these mechanisms won't cut it, because it isn't a requirement that channels communicate with anybody, except for contacting the directory when the account is created. I think we need to make every channel ping the directory once a month. Then we can find those that have not done so (after syncing with other directories). We can't have the directory just flag dead accounts as this would create a way for an anti-social attacker to become a directory server and mark all the accounts dead.
* preserve the source owner when creating a delivery fork so that we can ↵friendica2013-10-131-2/+3
| | | | uplink back to them without any ambiguity.
* Pieces we'll need to tie together chanman and account/channel deletion and ↵friendica2013-09-171-5/+30
| | | | | | | | directory sync. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. Please do not mess with any of this. OK? Understood?
* doc update, put more telemetry on notifier and try to ensure that private ↵friendica2013-09-131-0/+4
| | | | posts have recipients.
* perform a refresh_all when an import has completed so that all your ↵friendica2013-09-081-3/+2
| | | | connections get a fresh update.
* Add Comanche layouts to the things that don't go offsite.friendica2013-09-011-0/+4
|
* most of expire is now ported from friendica, but the protocol bits to push ↵friendica2013-08-141-4/+15
| | | | out the delete notifications for the entire batch to all recipients of the original post are not complete and will take quite a bit more work. As a consequence, expire has been completely disabled until it is fully implmented since it could result in completely un-removable posts reminiscent of the infamous "Bonnie Nadri" incident at Diaspora which we do not wish to re-live.
* block content-type (called ITEM_BUILDBLOCK to avoid confusion with content ↵friendica2013-08-121-0/+5
| | | | that is blocked)
* yhis should fix the privacy leak - as well as non-private replies to private ↵friendica2013-08-011-1/+4
| | | | posts
* privacy leakagefriendica2013-07-311-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 08:39:44 +0000