Also stripping id from foreign HTML messages (could interfere with UI) and disabled failing attachment popup for a.attachment links that don't have a proper id, so you can click through instead of getting an error.
Issues:
* any other links aren't marked and saved
* inconsistent behavior between local and remote attachments (local displays in lightbox, remote doesn't)
* if the enclosure'd object isn't referenced in the content, you won't be offered a link to it in our UI
We only need one author for user feeds: the user themselves. So, show
the user as the activity:subject, and don't repeat the same
activity:actor for every notice unnecessarily.
* 'testing' of gitorious.org:statusnet/mainline: (25 commits)
Fix a bunch of notice & warning-level messages that were breaking my inter-instance communications
more output in updateostatus.php
lost important fields when switching queries
show service debug info
pass listener URI into consumer for OMB
remove strict check on OMB exception strings
return correct HTTP status code for OMB errors
send smaller error pages for OMB API endpoints
Remove check for secret in token deletion on Subscription::cancel()
Better logging on bad token in subscription
Return empty array when no subscriptions to remote
drop tokens for OMB on unsubscribe
fix path for updateostatus.php
Script to convert OMB subscriptions to OStatus subscriptions
show service debug info
pass listener URI into consumer for OMB
remove strict check on OMB exception strings
return correct HTTP status code for OMB errors
send smaller error pages for OMB API endpoints
Remove check for secret in token deletion on Subscription::cancel()
...
In a federated system, "@nickname" is insufficient to uniquely
identify a user. However, it's a very convenient idiom. We need to
guess from context who 'nickname' refers to.
Previously, we were using the sender's profile (or what we knew about
them) as the only context. So, we assumed that they'd be mentioning to
someone they followed, or someone who followed them, or someone on
their own server.
Now, we include the notice information for context. We check to see if
the notice is a reply to another notice, and if the author of the
original notice has the nickname 'nickname', then the mention is
probably for them. Alternately, if the original notice mentions someone
with nickname 'nickname', then this notice is probably referring to
_them_.
Doing this kind of context sleuthing means we have to render the
content very late in the notice-saving process.
