tombofry / microlight Goto Github PK

• Should support logging in using IndieAuth. This will be done by checking that the login was performed by the identity created by the website's owner (but how do we manage initial set up?).
• Post management
  • Create post
  • Delete post
• Identity update form

Currently, if you send a webmention with a relative URL, it will be parsed successfully (as it's still technically a URL, just a relative one). This should be combined with the webmention source to create a full, absolute URL.

The website should have an identity associated with it. This means being able to create a h-card/vCard visible (or not), on the homepage, so that features such as IndieAuth will work.

Features:

• Recommend that users fill out specific social media accounts that are guaranteed to work with IndieAuth
• Start with a set number of potential accounts (email, twitter, github, facebook, etc) Email is required, everything else currently optional
• Allow users to add custom links/accounts
• Upload image from a form and correctly resize/store image

Currently, I am doing no preparation of the queries sent to the SQLite database. At least the following should happen:

• Escape all quotes, or encode them into HTML entities
• Post slug should accept alphanumeric, hyphen, and underscore characters ONLY
• Post tags should accept alphanumeric, space, hyphen, and underscore characters ONLY
• Post type should accept alphabetic characters ONLY

If you upload a non-square profile image, it will keep the aspect ratio and therefore look weird on the page. When setting up a site, crop any non-square image.

This seems to be specific to iOS, as it's fine on Firefox on Linux and Android.

The default theme should have the following properties:

• *Not look like it was made in notepad
• *KISS (https://en.wikipedia.org/wiki/KISS_principle)
• *h-entry formatting
• Briefly explain how theming works
• Support majority of post types

* Most important, all others are optional

Currently, the network request function only returns the body (or headers if the method is HEAD). However, it should return all of the following in an array:

• Response Body
• Return code
• HTTP Headers

While using quill, I couldn't publish a post unless I specified a value for the published field, as it would send an empty string.

The following tag isn't escaping the content value, which leads to broken open graph tags, although this will happen wherever there is quoted user content... 🤔

<meta property='og:description' content='...' />

All of the following features should both have functions related to them, and be present in the default theme.

In the default theme, they should all adhere to the h-entry standard.

• Pagination
• Tag Filters
• Types (theme dependant)
  • Article
  • Note
  • Audio
  • Photo
• Show metadata;
  • Location (if any)
  • Date published
  • Tags

Whether it’s a webmention issue or if it’s simply not parsing the payload provided by Quill, the micropub endpoint fails when posting a favourite using Quill. On mobile, at least, the error message is very vague, so some investigation needs to take place.

For reference, this is the URL I tried to post as a favourite.

It could also be a server issue while attempting to fetch the source contents.

UPDATE: It seemed to like my own post just fine. See this post. (This is all being done on mobile at the moment so all this text is basically a way for me to jot notes down for when I get to actually fixing the issue)

At the moment I try some social networks like Mastodon, Friendica or Diaspora with decentralized instances.

Would it possible with microlight to build such a site / server / instance? And communicate with other instances like Mastodon via activitypub / ostatus protocols?

I mean prepare local data to be send / received / shared to networks?

After quickly trying to visit http://[url]/microlight.db, where the database is stored as of the default configuration, it prompted me to download it. Uh oh!

Make sure files can't be downloaded from anywhere apart from the uploads directory.

I gave this a try.
After fixing the ROOT to correct setting
I could get to the first page alright.
But when I go to 'micropub' I get the error 'unauthorized'

How to log in?

Sites should be themeable, probably similarly to how hyperlight does it.

Give themes access to:

• Identity
  • Name
  • URL
  • rel=me links
  • Icon
• Posts (optionally limited to a specific number)
  • Replies, mentions, etc

If people comment, like, or repost one of your entries, this should be reflected on the entry page. This is likely going to require another database table (or two) to store them.

• Person table for storing unique individuals interacting.
• Interaction table, referring to a specific person and post.

However, because I value data collection and privacy, a disclaimer should be displayed somewhere on the page stating that their data can be permanently removed from the site by emailing the site owner. Hooray for GDPR!

• Create tables
• Display webmentions
• Webmention endpoint
  • Determine entry type on source URL
  • Determine post content on source URL
  • Determine published date on source URL
  • Determine author card details (image, name, URL)
  • Store interaction in database
  • Retrieve person from database if they already exist (instead of inserting)
  • Update person cache's image URL and name if they already exist
  • Support updating existing webmentions (which includes preventing duplicate interactions)
  • Support deleting existing webmentions (if, upon updating, the source URL return 410 Gone)
  • Limit fetching source contents to 5 seconds or 1MB of data
  • (optional) Provide CSRF token on a post's webmention URL and validate it before accepting. See Cross-Site Request Forgery.

An endpoint should be created to manage the upload of images to the website. If the image is wider than the owner's specified choice, it should resize it down, assuming the relevant library (GD or ImageMagick, haven't decided yet) is actively installed. Ideally, this should be implemented as a small library with largely reusable functions, so that the same functions can be used to upload the user's self-image when installing the site.

I don't know how I overlooked this. Usually, URLs are parsed before being accepted, although apparently not for webmention authors. 🤔

error profile image upload Some errors occurred during installation:
Image could not be saved to file

In order to support POSSE, social media accounts will either need an API key or an OAuth login to post new entries to said accounts on the user's behalf.

Problems:

• Where do you securely store the API keys/access tokens?
• How do you always make sure they are up to date?

Start simple, only allow the article or note post format for now, to get started.

Include the following metadata in an article:

• Title (p-name)
• Summary (p-summary)
• Post Content (e-content)
• Permalink (u-url)

This would mean any editor (such as quill, for example) could be used to create posts. This is arguably more important than the admin control panel #5

• Supports x-www-form-urlencoded or multipart/form-data
• POST to /micropub for h=entry
  • h = entry
  • name - If not provided, assume type is note, otherwise article
  • content for the main post content
  • summary - Make a max length of 160 for open graph? If not provided, take a snippet from content
  • photo (if file not provided)
  • in-reply-to, repost-of, like-of URLs
  • category[] for tags
  • mp-slug for manual slug entry (must return an error if the slug already exists).
• POST to /micropub using JSON Content-Type
  • Parse same items as above but ensure they are single element arrays
  • content may contain html key to create post as HTML.
• Create post, returning HTTP 201 status
• Update post, using action=update and returning HTTP 204 status
• Delete post, using action=delete and returning HTTP 204 status
• Requires authentication of user - must be same user as is hosting the website.
  • Create auth/callback script which validates the user via an IndieAuth site Almost, but this is not being implemented anymore (well, for now, at least).
• Support q=config to return media endpoint and syndication (maybe)
  • Return empty JSON object {} in the meantime, while neither of these features are implemented.
  • Support further additions to the GET micropub?q=[...] routes using micropub extensions

Eventually, set up an optional redis database (or equivalent) to cache the site's identity and the 10 (or whatever is set in the configuration) most recent posts, to speed up the website.

Currently, table creation SQL syntax is only specified for SQLite, however if Microlight is to support MySQL as well (and even PostgreSQL?), the syntax needs to support both formats.

This means that people are able to perform likes, replies, and mentions using their own website. See reply, webmentions, likes, and more.

If a post is created as a reply, like, or repost, with a specified URL, a webmention to that URL should be performed.

This is done by making a request to the URL and parsing the response headers and body for any links with relation to "webmention" (eg. <link rel="webmention" href="http://example.com/webmention" />). See Aaron Parecki's article on the matter, specifically under the "Automatically Sending Webmentions" section.

• When creating a post
• When updating a post
• When deleting a post

Currently, you can POST to the install script and it will add a user and links to the database without actually verifying that you were the one who actually filled in the form and pressed install.

Even on POST, it should check to see whether the database has already been set up before processing.

Currently, the location of a post is simply just a string. It would be nice if actual locations could be stored separately and include more details about them within posts, so check-ins would be better supported. This would mean adding another field to the main posts table to check for a location ID.

EDIT: Perhaps the location field could simply be a JSON-encoded string containing all fields related to location on the IndieWeb wiki.

After a post is created, it should be updateable. This can be displayed on the page with an "updated at" field.

Note that syndication should not necessarily be updated.

When a URL is included in the post - either as part of a like or bookmark post, for example, or included within the post's content - microlight should attempt to load the page details automatically and cache them in a database so that a preview for the link can be shown.

It would also be very handy if YouTube, SoundCloud, Bandcamp, etc. content could be embedded directly into the page, although this would require URL parsing of specific domains.