Added the following FIXME:
How should a Twitter user get their Inbox filled with foreign tweets?
Every imported Twitter user has a profile in the Profile table, so we
could setup a Subscription entry for each of those, meaning they get
collected in the InboxNoticeStream... But this would mean a lot of
unnecessary entries and listings that generally just point to the
locked down Twitter service.
Let's figure out a good relation so we can connect any profile to any
imported foreign notice, so it shows up in the "all" feed.
Also cleaned up and made typing stricter for the stream, so only
profiles can be submitted. This reasonably also means we can create
"inbox" or "all" streams for foreign profiles as well using the same
stream handler (but of course only for messages we already know about).
To avoid looking up posts for a long time in a large notice database,
the lookback period for the inbox is no longer than the profile creation
date. (this matches the behaviour of Inbox)
Inbox class can probably be removed now.
There was a problem with (specifically at least) PuSHpress for
Wordpress. A previous attempt to perform a DB transaction backfired
because the remote side could connect to the callback before our
commit had gone through.
I take full responsibility for introducing the bug in the first place :)
This will work without much extra effort because there will always be
more notices (higher value) than conversations (so no collisions).
But please run upgrade.php to avoid having an autoincrement id on
conversation table.
Installations using code after 2014-03-01 will have identical
conversation IDs to the initial (conversation root) notice IDs. This
will not affect older installations, which will have very different
values.
require_once lines were required since _plugins_ don't __autoload
Also, Realtime would load the wrong URL for css/js since $this->name()
returns get_class($this) instead of the calling class' __CLASS__.
Many of the microapps are pretty javascript dependant, but at least
we should allow users to get to the new notice field without allowing
javascript to run in the browser. :)
Minutely will NOT necessarily run by the minute, because it depends on
site visitors. Busy sites will be able to do this, but sites where the
visitors (or search engine stuff or api calls) are more than a minute
apart, the interval will be much larger.
Among other things (such as permanent subscriptions), Pubsubhubbub 0.4
removed the "sync" verification method. This means that any incoming
PuSH subscription requests that follow the 0.4 spec won't really
_require_that we handle it as a background process, but if we were to
try direct verification of the subscription - and fail - there's no way
we could pick up the ball again. So _essentially_ we require background
processing with retries.
This means we must implement something like the "poorman cron" or
similar, so background processing can be handled
on-demand/on-site-visit. This is how Friendica, Drupal etc. handles it
and is necessary for environments where we can't run separate queue
daemons.
When the poorman-cron-ish thing is implemented, auto-renewal will work
for all users.
PuSH 0.4 spec:
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
More on PuSH 0.4 release (incl. breaking changes):
https://groups.google.com/forum/#!msg/pubsubhubbub/7RPlYMds4RI/2mIHQTdV3aoJ
This is more of a proof of concept and will likely not stay in exactly
this form. We should reasonably deliver the entire notice upon webfinger
querying.
If you're using XMPP by setting $config['xmpp'][*] then you should do:
addPlugin('Xmpp', $config['xmpp']);
because setting it directly in $config[''] won't do anything.
Also, default resource for XMPP is now 'gnusocial'. If you want something
more random, set it in your addPlugin config array.
Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
"[...] posts _local_ users (like you) make won't get data about "repeated by"
from federated users"
This was because the ActivityObject would processShare where the shared object
has a _local_ 'actor' URI. Ostatus_profile would complain this meant that a
"Local user cannot be referenced as remote.".
So we see if the shared activity object's id (URI) is in our Notice table, so
we don't have to processActivity - and can skip ensureActivityObjectProfile.
Added the relevant section in INSTALL about queues and daemons to get
the plugin runnig.
Made resource required, as otherwise XMPPHP will send invalid from JIDs
in it's stanzas. For example when my configuration didn't had the
resource part, outbound stanzas looked like this:
<message
from="gnusocial@example.de/"
to="flow@example.de"
type='chat'>
<body>
User "flow" on GNU Social has said that your
XMPP/Jabber/GTalk screenname belongs to them.
…
</body>
</message>
Note the '/' at the end of the from attribute, without an actual
XMPP resource. But according to RFC6122 2.1 "every allowable portion of
a JID MUST NOT be zero bytes in length". Causing a jid-malformed
response from the server.
Also, it's nice to know that debug=true will print out all sent and
received stanzas, which helped me to debug the problem.
Furthermore I add a note that if the XMPP services uses DNS SRV records,
'host' has to be configured (in cases where service host != xmpp domain).
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
Nickname verifications on registration and updates for profiles (not yet
groups) have been improved.
Minor bugs in RegisterAction were also fixed, where multiple forms would
be outputed because the function did not return after showForm(). This
will be solved more permanently with throwing exceptions in the future.
I implemented changes from quitter.se's new API that their front-end qvitter
uses, https://github.com/hannesmannerheim/qvitter/blob/master/api-changes-1.1.1/CHANGES
However I left out the URL shortening commens, since I believe whatever behaviour
they experienced that caused them to implement this was a bug (or many) and should
be fixed in their proper areas and that shortening should not be entirely left
out in API calls.
We're also now using $config['image']['jpegquality'] to determine the
quality setting for resized images.
To set Avatar max size, adjust $config['avatar']['maxsize']
The getAvatar call now throws exceptions too. Related changes applied.
Now let's move Profile->avatarUrl to the Avatar class!
XML_XRD::getAll requires arguments (at least relation). If one really
want all links, just get the 'links' array. It's public!
Also, not all XML_XRD_Element_Link were migrated from the previous
array style.
* getOriginal added to Avatar class
This is a static function that retrieves the original avatar in a leaner
way than Profile->getOriginalAvatar() did (see below).
This will throw an Exception if there was none to be found.
* getProfileAvatars added to Avatar class
This gets all Avatars from a profile and returns them in an array.
* newSize added to Avatar class
This will scale an original avatar or throw an Exception (originally from
Avatar::getOriginal) if one wasn't found.
* deleteFromProfile added to Avatar class
Deletes all avatars for a Profile. This makes the code much smarter when
removing all avatars from a user.
Previously only specific, hardcoded (through constants) sizes would be
deleted. If you ever changed lib/framework.php then many oddsized avatars
would remain with the old method.
* Migrated Profile class to new Avatar::getOriginal support
Profile class now uses Avatar::getOriginal through its own
$this->getOriginalAvatar and thus remains backwards compatible.
* Updating stock GNU Social to use Avatar::getOriginal
All places where core StatusNet code used the
$profile->getOriginalAvatar, it will now useAvatar::getOriginal with
proper error handling.
* Updated Profile class to use Avatar::newSize
When doing setOriginal, the scaling will be done with the new method
introduced in this merge.
This also edits the _fillAvatar function to avoid adding NULL values to
the array (which causes errors when attempting to access array entries as
objects). See issue #3478 at http://status.net/open-source/issues/3478
New plugins:
* LRDD
LRDD implements client-side RFC6415 and RFC7033 resource descriptor
discovery procedures. I.e. LRDD, host-meta and WebFinger stuff.
OStatus and OpenID now depend on the LRDD plugin (XML_XRD).
* WebFinger
This plugin implements the server-side of RFC6415 and RFC7033. Note:
WebFinger technically doesn't handle XRD, but we serve both that and
JRD (JSON Resource Descriptor), depending on Accept header and one
ugly hack to check for old StatusNet installations.
WebFinger depends on LRDD.
We might make this even prettier by using Net_WebFinger, but it is not
currently RFC7033 compliant (no /.well-known/webfinger resource GETs).
Disabling the WebFinger plugin would effectively render your site non-
federated (which might be desired on a private site).
Disabling the LRDD plugin would make your site unable to do modern web
URI lookups (making life just a little bit harder).
Allow the OStatus queue-handler to handle all posts,
and give it the smarts required to make correct decisions
about whether it should or shouldn't relay notices
over OStatus.
cf. http://status.net/open-source/issues/3540
Conflicts (staticGet => getKV):
plugins/OStatus/lib/ostatusqueuehandler.php
