It's better in how it's organised and extensible. See the examples below to have -an idea.
- -To extend an Activity properties you do:
- -public function onActivityPubValidateActivityStreamsTwoData(string $type_name, array &$validators): bool {
- if ($type_name === '{Type}') {
- $validators['attribute'] = myValidator::class;
- }
- return Event::next;
-}
-The Validator should be of the form:
- -class myValidator extends Plugin\ActivityPub\Util\ModelValidator
-{
- /**
- * Validate Attribute's value
- *
- * @param mixed $value from JSON's attribute
- * @param mixed $container A {Type}
- * @return bool
- * @throws Exception
- */
- public function validate($value, $container): bool
- {
- // Validate that container is a {Type}
- Util::subclassOf($container, Type\Extended\Object\{Type}::class, true);
-
- return {Validation Result};
-To act on received activities do:
- -public function onActivityPubNew{Type}(&$obj): bool {
-To add information to Activities being federated by ActivityPub do:
- -public function ActivityPubAddActivityStreamsTwoData(string $type_name, &$type): bool {
-To implement an ActivityStreams 2.0 representation do:
- -public function onActivityPubActivityStreamsTwoResponse(string $route, arrray $vars, ?TypeResponse &$response = null): bool {
- if ($route === '{Object route}') {
- $response = ModelResponse::handle($vars[{Object}]);
- return Event::stop;
- }
- return Event::next;
-}
-Contrary to the original plan, we have merged The Free Network Module, WebFinger and LRDD into a single component named FreeNetwork. Likewise, ActivityPub and ActivityStreams 2.0 was kept the same plugin instead of separated.
- -The FreeNetwork component adds WebFinger (RFC7033) lookup and implements Link-based Resource Descriptor Discovery (LRDD) based on RFC6415, Web Host Metadata. It takes and produces both Extensible Resource Descriptor (XRD) and JSON (JavaSript Object Notation). Furthermore, and different from v2, every federation protocol will use the same distribution queue maintained by this component instead of holding its own.
- -We originally intended to have data modelling plugins that would extend the GS's "language". We then understood that it added more complexity than we wanted without any considerable advantage because we cannot dissociate data reception handling of the protocol itself.
- -ActivityPub already translates between activity and entity and allows plugins to extend it (thus serving a similar purpose to data modelling and representation plugins).
- -GNU social v3 now supports mentions, which is a process that starts in the Posting component. The processing of local mentions naturally finds its entire handling here.
- -For remote ActivityPub mentions, ActivityPub handles it aided by the FreeNetwork component).
- -We still have to port OStatus (and ActivityStreams 1.0) and implement the distribution by FreeNetwork, although the base work is done. Regarding ActivityPub, although some of it already works, expanding the existing plugins to supplement ActivityPub, and full validation isn't ready yet. We will most likely finish the implementation of the whole federation stack in the next week.
- - - - - - -]]>GNU social now has its documentation available in -https://docs.gnusocial.rocks/. It features four -different books. These are automatically generated from the source using mdBook.
- --- -Only the development book is in an elaborated state, the other books are -holding for more ready code.
-
And two of them are new:
- -And two of them are updates from existing documentation:
- -Together with the documentation we've introduced a -wiki. Its purpose is to walk-through decisions, -convention, terminology. It's where we document the reasoning the development team went -through before implementing more sophisticated functionalities.
- -Finally, when the documentation doesn't explain, and to ensure the whole code -is properly tested, we have the -tests. And the coverage is available here. At the time of writing the coverage has 98.76% code lines tested.
- - - - - - +It's better in how it's organised and extensible, check the EVENTS.md for examples.
+File Storage in GNU social is used for avatars, for notes containing -attachments, and for notes containing links (in which case is an Embed preview). -Notes can be created by local users or fetched from remote actors. Filehash is -used to reduce file duplication.
- -When a user shares a Link that uses OpenGraph tags or has an OEmbed provider, -the Embed plugin generates a preview for it that may contain a thumbnail.
- -When a user shares a Link to an image, the StoreRemoteMedia plugin can fetch the -file and make it available as an attachment, and will generate a thumbnail.
- -When an image, video, or other file type is uploaded or retrieved, an Attachment -entity is created. When a thumbnail is requested, one is generated if an -EncoderPlugin that supports the mime type is available.
- -There are two EncoderPlugins implemented:
- -Another helpful plugin is FileQuota which ensures a user stays under the file quota.
- -There are various entities related to attachment and thumbnail handling. -The key ones are:
- - - -The plugins are able to act by means of the Events system, as elaborated in the -documentation.
- - - - - - - - - - - - - - -]]>GNU social v2 has tags and lists. It allows you to:
-- search for an #hashtag and see a stream of notes tagged with it;
-- make lists of actors and mention them with @#list_name
-- self tag and enter a list of people in your instance with the same self tag
GNU social v2 has tags and lists. It allows you to:
+ +#hashtag and see a stream of notes tagged with it;@#list_nameIt is limited with regards to federation of self tags and the @#list_name can't
target remote actors even when they are inside your list.
Its controller handles upload, update and removal.
- -Important change from v2: Avatars are now regular attachments.
- - - - - - - - - - - - - - - - - - - - - +The primary use of GNU social is to access the free network, be it ActivityWeb (ActivityPub) or Fediverse (OStatus).
+Contrary to the original plan, we have merged The Free Network Module, WebFinger and LRDD into a single component named FreeNetwork. Likewise, ActivityPub and ActivityStreams 2.0 was kept the same plugin instead of separated.
+The FreeNetwork component adds WebFinger (RFC7033) lookup and implements Link-based Resource Descriptor Discovery (LRDD) based on RFC6415, Web Host Metadata. It takes and produces both Extensible Resource Descriptor (XRD) and JSON (JavaSript Object Notation). Furthermore, and different from v2, every federation protocol will use the same distribution queue maintained by this component instead of holding its own.
+ +We originally intended to have data modelling plugins that would extend the GS's "language". We then understood that it added more complexity than we wanted without any considerable advantage because we cannot dissociate data reception handling of the protocol itself.
+ +ActivityPub already translates between activity and entity and allows plugins to extend it (thus serving a similar purpose to data modelling and representation plugins).
+ +GNU social v3 now supports mentions, which is a process that starts in the Posting component. The processing of local mentions naturally finds its entire handling here.
+ +For remote ActivityPub mentions, ActivityPub handles it aided by the FreeNetwork component).
+ +We still have to port OStatus (and ActivityStreams 1.0) and implement the distribution by FreeNetwork, although the base work is done. Regarding ActivityPub, although some of it already works, expanding the existing plugins to supplement ActivityPub, and full validation isn't ready yet. We will most likely finish the implementation of the whole federation stack in the next week.
@@ -482,21 +306,96 @@ Updates: Finish the Avatar component + +]]>We hope you like it!
+++Modern looking, consistent and accessible UI across all browsers. +Non-JS version as the primary focus, JS is optional and should be regarded as such.
+
The Web is 95% typography, the art and technique of arranging type to make text more readable and pleasing. +To achieve this, a textual hierarchy is fundamental, text should present a clear, readable structure to the reader. +In much of the same fashion, the way we perceive Web pages relies upon the same fundamentals. As such, by focusing on the +markup, we hope to achieve an accessible, fast and polished structure by which any browser and screen reader relies upon.
+The git +history is clear (we believe), but it can be challenging and obscure to outsiders and non-technical people.
+With the introduction of this blog made with +bashblog, we hope to make all the progress more visible and easier of following :)
+It has a RSS feed so, don't +forget to subscribe!
@@ -528,10 +427,10 @@ Updates: Finish the Avatar component -]]>