Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Work In Progress] Full Article Rendering Support #1048

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@dariusk
Copy link

commented May 13, 2019

Mostly I want to get people's opinion on this feature I've added to my fork at friendcamp/mastodon. I would like feedback on this both in terms of the implementation of the feature for users, the technical implementation, and also whether Glitch would want this.

The end result

The idea is to provide a "read article" link similar to "read more" when Mastodon receives an AP object of Article type. So if you subscribe directly to a blog on write.as or similar, you can read the full article in Mastodon.

How it appears in timelines and on profiles:

image

How it appears when you click to see the full article on a phone:

image

Here's how the full article renders (looooong screenshot so not embedded)

very long screenshot

Tech notes

This is my first time adding a column to a table in Rails. I'm probably doing something wrong in terms of database design. My implementation generally feels a little "hacky" and I'm sure there are more elegant solutions. I'm happy to implement these if someone will suggest to me what they are.

I've made a new activity_type column in the statuses table which at the moment says "Article" if the server sees an Article object come in, but is otherwise empty. This field is used to then change how the server renders what's in there.

A note on images

Inline images for posts are cached locally the moment the object is received by the server, so user IPs aren't exposed when they read an article with images on their client. I use the same mechanism that already exists for creating media attachments.

dariusk added some commits Apr 30, 2019

Adding full Article support
This creates a new column in the `statuses` table which keeps track of
activity_pub_type, so in the case of a Note it will be blank (the
default) and it will be a string "Article" if the received remote object
is an AP Article. There is now a bunch of special case code in the
formatters and sanitizers to handle Articles differently, as well as on
the clientside.
@dariusk

This comment has been minimized.

Copy link
Author

commented May 13, 2019

Would especially like @ThibG to look at this since it is dependent on his rich text commits.

@ashkitten

This comment has been minimized.

Copy link

commented May 13, 2019

i had been thinking about how to add this, and i figured that a modal would be the best (at least for me) way to display articles (and long posts in general). that way you can still get the full reading experience without feeling crammed into one column on a large display

media_attachment = MediaAttachment.create(account: @account, remote_url: src, description: handler.alts[src], focus: nil)
media_attachment.file_remote_url = src
media_attachment.save
if unsupported_media_type?(media_attachment.file.content_type)

This comment has been minimized.

Copy link
@dariusk

dariusk May 13, 2019

Author

This is only the reported content-type from the remote server, but I think checking against this is consistent with how Mastodon does it (I couldn't find any code where mastodon checks to see if received MIME types are consistent with, for example, actual file headers).

@ThibG

This comment has been minimized.

Copy link

commented May 15, 2019

Thank you! As @ashkitten said, I think a modal could make more sense, to view the article independently and not have its width restricted to that of a Mastodon column.

I have another concern wrt. handling HTML tags from articles, I fear we may somehow lag behind in term of implementing support for what I expect could be a wider range of HTML than for notes… but maybe I'm wrong, and that range won't necessarily be larger. And maybe even if it is, we could detect it dynamically and offer a link fallback.

Otherwise, this seems good, but I have not looked at the code yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.