Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | improvement in source route checking when handling complex *upstream* ↵ | friendica | 2014-10-10 | 1 | -6/+19 |
| | | | | delivery chains, which were not adequately accounted for in the earlier checkin. | ||||
* | allow (our own) ajax urls to pass through bbcode intact. | friendica | 2014-10-09 | 1 | -1/+2 |
| | |||||
* | OK this is important. So read it carefully. | friendica | 2014-10-09 | 1 | -3/+33 |
| | | | | | | | | This checkin implements route matching of comments so that they are only accepted from the same route as the top-level post they are attached to. This way there should be no mis-match of permissions between any posts in the thread. It may not be completely compatible with comments posted in the past (though I've tried to be, there may be some minor issues). In addition it seems that relaying was invoked more often than necessary - especially when a duplicate post arrived which was not processed because the edited time hadn't changed - it still invoked relaying. This fix should improve site performance considerably for comments cross-posted to forums; which got bounced around a bit and delivered redundantly for no reason. Roll this back *only* if it causes a meltdown or comment loss is "serious" (as in OMG people are dying, make it stop!). If we can get past 24 hours without serious issue we need to get everybody onto this code. There may be some minor comment loss (mostly affecting new comments to older posts or likes of older comments) until the majority of sites have moved to the new code. It may be difficult or impossible to deliver comments to posts that pre-date the addition of source routes (April 1, 2014) to anybody but the top-level post author at his/her primary hub. We may wish to close comments on these posts, but let's see how we go before doing that. | ||||
* | ability to pre-populate connections for new channels. e.g. "MySpace Tom" | friendica | 2014-10-01 | 1 | -2/+0 |
| | |||||
* | found the sucker | friendica | 2014-09-22 | 1 | -2/+2 |
| | |||||
* | just mark dead hubloc deleted - don't remove them. This could cause ↵ | friendica | 2014-09-16 | 1 | -2/+4 |
| | | | | problems. Also clean up fetch_url/post_url header option | ||||
* | honour service class restrictions for total_identities, total_channels ↵ | friendica | 2014-09-15 | 1 | -4/+36 |
| | | | | ("friends") and total_feeds both when importing channels and subsequently when syncing clones. Limits are based on the local system - additional entries are silently dropped. | ||||
* | provide a way to sync locations and get rid of bogus hublocs, now implemented | friendica | 2014-09-14 | 1 | -2/+8 |
| | |||||
* | pull the plug on the old location sync section of import_xchan - this has ↵ | friendica | 2014-09-14 | 1 | -168/+12 |
| | | | | | | now been split off into its own function. Cross fingers because this is core functionality which was tried and true, well tested; and now it's a bit different. Please revert this if the matrix breaks in the next few hours. | ||||
* | more heavy lifting on the hubloc management and revocation infrastructure; ↵ | friendica | 2014-09-14 | 1 | -10/+51 |
| | | | | don't rush me. This is going to become a fundamental part of zot. It deserves careful consideration. | ||||
* | some backend work for the remaining missing bits of mod_hubman - this is ↵ | friendica | 2014-09-13 | 1 | -2/+200 |
| | | | | still a fair ways from being complete and is not ready for prime time. Basically we'll let a channel send out a public message saying "these are my currently approved locations" and anything that isn't in the list will be marked deleted. We'll send out this message when locations change somehow - either through direct personal involvement (hub revoke, change primary, channel import) or during a system rename or "find bad/obsolete hublocs" activity. This way we won't have clones sending back location info we just got rid of and re-importing the bad entries. | ||||
* | don't allow an xchan to be imported with an empty name. To avoid translation ↵ | friendica | 2014-09-11 | 1 | -2/+2 |
| | | | | issues we'll just make it '-'. | ||||
* | This is long overdue - use a symblic constant NULL_DATE instead of the ↵ | friendica | 2014-09-08 | 1 | -1/+1 |
| | | | | easily mis-typed sequence '0000-00-00 00:00:00' | ||||
* | realm detection logic reversed | friendica | 2014-09-04 | 1 | -1/+1 |
| | |||||
* | sql error in profile_activity | friendica | 2014-08-31 | 1 | -4/+2 |
| | |||||
* | lots of little Diaspora issues | friendica | 2014-08-28 | 1 | -6/+7 |
| | |||||
* | works one way sort of - now to go the other way - which will require fixing ↵ | friendica | 2014-08-26 | 1 | -1/+4 |
| | | | | a whole slew of FIXMEs | ||||
* | sort out some anomalies | friendica | 2014-08-25 | 1 | -1/+12 |
| | |||||
* | We really can't do this without a hubloc. I was hoping we could, but ↵ | friendica | 2014-08-22 | 1 | -2/+3 |
| | | | | notifier is setup to take hublocs, not xchans. | ||||
* | provide the site blacklist everywhere it is needed | friendica | 2014-08-21 | 1 | -0/+16 |
| | |||||
* | some more work on realms | friendica | 2014-08-17 | 1 | -3/+4 |
| | |||||
* | add collections widget to connections page - and some more work on realms | friendica | 2014-08-17 | 1 | -1/+15 |
| | |||||
* | provide backend storage and declaration of directory realm | friendica | 2014-08-16 | 1 | -2/+5 |
| | |||||
* | don't block "public" messages with authenticated scope | zottel | 2014-08-15 | 1 | -1/+1 |
| | |||||
* | zot logging to figure out why we occasionally don't have an address on ↵ | friendica | 2014-08-12 | 1 | -0/+4 |
| | | | | xchan_import - I suspect we don't have anything useful at all. | ||||
* | got the logic reversed on that one | friendica | 2014-08-07 | 1 | -1/+1 |
| | |||||
* | over-ride the private flag if we received a post that isn't completely ↵ | friendica | 2014-08-07 | 1 | -1/+13 |
| | | | | public, but they didn't set the private flag. | ||||
* | public scope delivery issues | friendica | 2014-08-06 | 1 | -3/+11 |
| | |||||
* | clone sync of "unfriend" actions | friendica | 2014-08-05 | 1 | -0/+15 |
| | |||||
* | add an encoding type to formatted zot communication structures so that we ↵ | friendica | 2014-07-24 | 1 | -5/+1 |
| | | | | can later add alternate encodings. | ||||
* | ensure that we don't have permission settings issues due to version skew ↵ | friendica | 2014-07-17 | 1 | -1/+1 |
| | | | | across sites. | ||||
* | collection sync issue | friendica | 2014-07-17 | 1 | -0/+25 |
| | |||||
* | collection sync | friendica | 2014-07-16 | 1 | -0/+114 |
| | |||||
* | limit fields to what we require | friendica | 2014-07-14 | 1 | -1/+1 |
| | |||||
* | index collection sync info by hash rather than id | friendica | 2014-07-14 | 1 | -1/+1 |
| | |||||
* | clean up more code duplication | friendica | 2014-07-14 | 1 | -6/+20 |
| | |||||
* | the sending side of clone syncing of collection/privacy_group information. ↵ | friendica | 2014-07-14 | 1 | -1/+15 |
| | | | | The receiving side is not yet implemented. | ||||
* | much better fix to problem yesterday of updates with the wrong ud_addr ↵ | friendica | 2014-06-30 | 1 | -23/+16 |
| | | | | | | getting updated. Now we'll pass in the update table row to import_xchan so we know exactly which ud_addr applies. We still need ud_flags passed in separately. | ||||
* | control chars crept in. | friendica | 2014-06-30 | 1 | -1/+1 |
| | |||||
* | ensure we have a unique guid for each address if one is generated. | friendica | 2014-06-30 | 1 | -1/+1 |
| | |||||
* | update the update records for all addresses attached to this channel, not ↵ | friendica | 2014-06-30 | 1 | -7/+19 |
| | | | | just the primary. | ||||
* | Implements a new permission level PERMS_PENDING | Alexandre Hannud Abdo | 2014-06-19 | 1 | -11/+15 |
| | | | | | | | | | | | | | | | | With this a user can allow some action to any user which connects to them, even before they've connected back. Ref. https://mobiliza.org.br/display/478d9e71eaf55748dc646d3990651d6d34cfb7db5c38360538ec730ca3ccf908@zothub.com Also some code cleanup and an alternative logic for handling notifications of permission changes in zot.php. This assumes that private posts are still restricted to people in your addressbook. Regardless of your global permissions, a pending channel won't get private posts, even if the post only has a deny clause not matching the pending channel. | ||||
* | note work still remaining | friendica | 2014-06-17 | 1 | -0/+1 |
| | |||||
* | sync profiles to nomadic clones | friendica | 2014-06-17 | 1 | -0/+39 |
| | |||||
* | send new connection notification even if auto-perms are set | friendica | 2014-06-12 | 1 | -1/+1 |
| | |||||
* | duplicate birthday events showing up | friendica | 2014-06-04 | 1 | -0/+7 |
| | |||||
* | bring back birthdays | friendica | 2014-06-02 | 1 | -2/+11 |
| | |||||
* | Merge branch 'master' into newevent | friendica | 2014-05-29 | 1 | -1/+21 |
|\ | | | | | | | | | Conflicts: include/zot.php | ||||
| * | cleanup dead directory entries. This was a real b#tch, so keep your eye out ↵ | friendica | 2014-05-28 | 1 | -0/+18 |
| | | | | | | | | for issues - which you shouldn't see until next weekend when this is scheduled to run. We're only setting flags, so if anything goes wrong we should be able to recover without too much pain. | ||||
| * | add activity_received hook | friendica | 2014-05-13 | 1 | -0/+3 |
| | |