DEVELOPING PRISMO ###### date: 2018-09-22, author: [jox](https://matrix.to/#/@joel_olbrich:matrix.org) For the development of the [WIP](https://wikipedia.org/wiki/Work_in_progress)-software [prismo](https://gitlab.com/mbajur/prismo) there is a matrix room open for discussion. A few days ago there happened to be an interesting [discussion](https://is.gd/nSKGxD) in there. Some arguments, that the participants [swedneck](https://matrix.to/#/@swedneck:swedneck.xyz)s and [mxb](https://matrix.to/#/@mxb:matrix.org)s and some other brought up, stuck with me and have made me think. The following summary is the result of my considerations. --- Up to this point the following way seems like a reasonable way to me for handling subreddits (and federation of them). **_IMPORTANT NOTE! Please keep in mind while reading this summary that I'm just spinning my thoughts through to the end._** Maybe it gives you, [mxb](https://matrix.to/#/@mxb:matrix.org), also inspiration to any other useful idea for the project. I hope so! :-) --- ## I'll start off with two points; ##### 1. Reviewing the term `groups` As another term for subreddit I suppose `PrismoRays`, since the projects name is **prismo**, or maybe even better; `PrismoSubs`, this time also including the syllable `sub`, to address ex-redditors. The approach of `Prismosubs` in my opinion also fits smoothly into the URL- when calling `sub` (as the subreddit, prismosub) on the next level in the hirarchie - after `prismo`. Like > [`https://instance.org/prismo/sub/linux/`](#), or > [`https://prismo.instance.org/sub/linux`](#) I personally also find that the wording sounds pretty nice, since you could kinda _sub_-scribe to a prismosub :-) ##### 2. A question that came up on my side when reflecting our discussion so far (I managed to find an answer to this though, I will unveil it later) Imagine I have [prismo.me.org](#) as an instance and I give birth (please stay with me, the wording is on purpose) to the sub [`prismo.me.org/sub/linux`](#). I guess, I am now the moderator of `#linux`. Right? But, shortly before the birth of `#linux` on my server, my internet connection was cut down, which means the new prismosub that was created could not be federated. In the meantime you have your server, and also give birth to [`prismo.you.org/sub/linux`](#) - the same happens here, you have full moderating power to `#linux`. Now my internet connection comes up again - and the two existing `#linux` have to compete against each other and to argue about the question who of them is the "real" one. ###### Question: In this situation which `#linux` wins? Who of us can keep the moderating-powers for `#linux`? --- ## Recap In [this video](https://hooktube.com/watch?v=tlI022aUWQQ) CPGGrey explains what reddit was like, initially. It was basically an aggregated list of stuff that people found online that they wanted to share with the world (for whatever reasons). Coming from that defintion, we could say, that prismo works the same way, but is much more than only this one feature. What I envision, when speaking of _more_, is, that **prismo could accomplish the following two (and a half) main features**; + **news/recommendations, distributed over the various prismosubs**, based on interests the users participate in, + the "half" feature, **different localities to discuss the interests/topics of each prismosub**. This is, were prismo could be build on top of the matrix-concept for [matrix](#)-rooms, and + **news/recommendations based on social connections** - the local timeline of my instance, and my overview page of the actions of the social connections (local&external) that I'm interacting with. Local timelines would be an highly interesting _social aspect_ for me (as the user) - that would affect the real connections between me and my friends and family that are perhaps on the same instance as me (or maybe they're not). --- ##### First feature So, some background to my thoughts about the first feature: Sometimes, when being on prismo, I would only engage in the prismosubs I'm interested in. Maybe, some other times, for example when I'm at work, I would need to find something regarding to a specific topic (if I don't know which prismosub could have the info I'm searching for, I probably could find help in [`HelpMeFindAPrismoSub`](#)). In that case, the allocation of prismosubs into different parts on different instances could, if implemented as absolute mirroring of all content on every instance, mean that **all subs contain the same content/information, no matter from what place in the network you join**. Which would really come in handy, since then you had *all the data* and wouldn't have the possibility to "miss something out". But this synchronisation maybe isn't possible at all, just by how the design of decentralisation is naturally. ###### To sum this part up: Since the comfort of "one big pot" of information seems not to be possible, I dislike the _idea_ of having various different localities where similar topics of a prismosub get discussed, while the participants of each locality don't know of each other at all. Again, I will get to this later. --- ##### Second feature Coming to the second feature: But sometimes I want also to connect with my friends and families, and see what they are up to. Assuming that my family is on my instance, and my friends are on their own family-instance, I could find new interesting stuff from looking through the listing of actions my family recently took that are filtered onto the local timeline. Or I could connect onto the local timeline on my friends instance if he allowed me to do so, and scroll through what he and/or his family were up to. (Maybe I even could subscribe to their local timeline, but _this_ indeed is another issue, that could easily be solved by implementing [`.rss`](https://wikipedia.org/wiki/RSS)) --- ## Approach to a feasable solution So, I've mentioned two times my approach for the (what looks to me as a) feasable solution, and this is it: Subreddits/Prismosubs are communities/groups whose character is, that the content that they hold is aggregated around interests / allocated into topics, which are federated in a way that everyone, in the whole network, can see, follow and participate with them - be it a user at the local instance or from an external instance (in the initial state, disregarding possible blocks/mutes). _Note that every prismosub gets a **unique** ID that is defined by the "birth-giving" server. It can used when experimenting with filtering data to create individual views on a enduser-frontend._ ##### Sharing prismosubs that are distributed across various instances When a `#linux` comes across another `#linux` (and with time there will come across even many more other `#linux`s), they can decide to integrate their content to each others **public** prismosub-list, and to share from this point on everything together. They say, that they know the other `#linux` and that they won't forget each other. Just like they were real persons that just became friends. (But as I understood this is not how it would technically work: in ActivityPub serverA won't send posts that reached serverA to serverB. In ActivityPub serverB has to lookup by himself if serverA got new content ready) ##### Following In principle, I am against the idea of following every instance that comes run along. But on the contrary, I'm not really convinced either that all connections would have to be made manually. What I consider an important plus point that we can implement in Prismo, and probably have a significant advantage to similar software approaches, is to provide an admin panel that lists all newly opened instances. The admin can then act to this list, either by asking his local users whether they think an instance is worth following or not, or by looking at the instance by himself and decide then. Conceptually, maintaining the list in the admin-panel could work the same way as how individual nodes in the [bitmessage](https://wikipedia.org/wiki/Bitmessage)-network connect themselves with each other. ##### Moderation Moderating-powers for a prismosub will stay on the respective instance (regarding the on-that-instance-created content only), and the content of the public prismosub-list will be mixed together with the local content. If the admin of [prismo.good.instance](#) sees that [prismo.bad.instance](#) tries to manipulate upvotes, or posts and comments spam, he can decide to cut [prismo.bad.instance](#) out of the conglomerated content on [prismo.good.instance](#). (Deductively, [prismo.good.instance](#) also won't share anything to [prismo.any-other.instance](#) about [prismo.bad.instance](#) anymore.) ##### Example If we had an instance with two users, user1 and user2, that would be participating in `#linux` and `#proprietary`, we would have at least **eight possible lists/views** on our instance: - ###### `#linux` public list, which contained all content that was created locally merged together with every external content - ###### `#linux` local list, which contained only the locally created content - ###### `#proprietary` public list, same as above - ###### `#proprietary` local list, same as above - ###### Overview for user1, which contained all content by user1 - ###### Overview for user2, which contained all content by user2 - ###### Local list, which contained all content created either by user1 or user2 - ###### Federated list, which contained all content that was named on the other list items. If we decided to apply blocks or mutes upon the processed content on our server, it would be applied to the view `Federated list` _first_, since this were the main list for the instance. All other views are just extracted data from that view. ##### More options/features Optionally we could add some other views, of course, named `Global view` or `Personal view`. For those there would be a different filter that were applied to the uncensored data, that were available to access in the network. **But, since the admin of the server can be held reliable by legal law, it must be an option for him to opt-in, _not_ to opt-out!** ##### Manual personalizing for the user If the admin is really strict and mutes many stuff he just personally dislikes, or if he decides not to block/mute something a user reported, we could give the users the option to have a personal block/mute-,unblock/unmute-list, with which they could disactivate/activate/reactivate personal filtering. I guess this probably accomplishes what was called `multireddits` in reddit. Maybe it was also nice for the user to have multiple personal views. --- ## Background about how I remember reddit I for myself did use reddit most of the time - _in the posts_: to "read a newspaper" (literally in the same sense as cpggrey described in his video, link is at the recap section) that is filled just by recommendations of people that are interested in the same topic as I am, or to recommend something myself, and - _in the comments_: to share information, get help, exchange thoughts and confront personal views to some aspect of a topic to learn something new. This is what reddit represented to me, and I would be very happy when it were possible to design prismo in a way that promotes these useful effects to appear again. --- ## Some more technical ideas to that the review: A sub could have - a welcome page `prismo/sub/linux/about` - a wiki `prismo/sub/linux/wiki` - the listing of all the posts `prismo/sub/linux/post/j2P3f` with the posts, that contain the comments `prismo/sub/linux/post/j2P3f/comment/Mn89w7cH` Every instances would have to maintain their own version of those pages, just as the various Peertube- and Mastodon-instances do.