This also fixes a problem with "initial salmon slap", which was a
problem for newly registered accounts which would have their first
salmon slap fail to distribute since there was a problem with Magicsig
keys. Apparently we have to re-read them with importKeys so the
Crypt_RSA objects publicKey and privateKey match later instances of them.
I think it may have been that generate() doesn't specify a signatureMode,
but I leave experimentation of that to the future.
We don't run a service similar to update.status.net yet. Maybe we should,
but that's for the future to decide. Currently I view it as a callback
that we want to avoid.
htmLawed cleans stuff out properly, but there's no very good way right
now to show text/html attachments, since everything gets jumbled up with
our own CSS etc. Best would be an iframe or just a new tab or so.
Conversation trees works pretty bad with the current layout, javascript
etc. So it's best if we separate it and work on it as a side-project. The
oldschool settings are currently being deprecated (or broken out like this).
I'll wait with removing User preferences for oldschool conversation tree,
since that might be reusable data. But I guess it will go in the near future.
Make the logic match the intent described in the comments.
The intent is clearly "accept notices whenever (A or B or C)", but
the logic implemented was more like "not ((not A) or (not B) or (not C))",
which is a basical boolean algebra fail (each of those ORs need to
become ANDs for double-negation to work).
The practical implication was that, for example, writing a reply
to someone else's notice and including an @-reference to _another_
user on another site to bring them into the discussion would
fail to deliver the notice to the new user because their server
would basically say `oh no, you can't message this user
from someone else's thread' because an earlier check for
the `A' or `C' parts of `(A or B or C)' prevents `B' from
being checked.
cf.: <http://status.hackerposse.com/notice/55846>, which was
refused by the nhcrossing.com server because it didn't know
about <http://sn.jonkman.ca/notice/93724>, even though it would
have passed the later `notice contains a reference to a local user'
check if not for an exception being prematurely thrown.
The whole idea of reporting `which specific check FAILED'
in an `if ANY SUCCEEDS' analysis is just bogus, so nix all of
the distinct ClientExceptions--a single `ALL FAILED' exception
is the only one that makes sense.
Read more at http://microformats.org/
Also, tooltip text on time representation for humans has been improved.
Unfortunately no standardised representation (like "RFC850") had 4-digit years.
The File object now stores width and height of files that can
supply this kind of information. Formats which we can not read
natively in PHP do not currently benefit from this. However an
event hook will be introduced later.
The CreateFileImageThumbnail event is renamed to:
CreateFileImageThumbnailSource to clarify that the hooks should not
generate their own thumbnails but only the source image. Also it now
accepts File objects, not MediaFile objects.
The thumbnail generation is documented in the source code. For
developers, call 'getThumbnail' on a File object and hope for the best.
Default thumbnail sizes have increased to be more appealing.
The exception thrown from MediaFile will be caught and simply result in
no thumbnail at all right now. In the future we might use a catch-all
and have a "cannot generate preview"-icon or something.
VideoThumbnails requires php5-ffmpeg and php5-gd.
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
