Because it’s a permalink I guess. It’s not set in stone though.
PS. Sorry for the late reply, been a bit out of the social loop.
- 3 Posts
- 42 Comments
Joined 6 years ago
Cake day: April 18th, 2019
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
I feel like you are projecting a lot of negative experiences you had elsewhere on the internet on lemmy, it’s devs and mods.
That kind of negativity is unwarranted and is exactly (in my opinion as a someone not affiliated with lemmy) one “unwritten” rule that you should really know about without having to explicitly see it in a list: you don’t go to someone’s house and shit in their living room.
The good part of lemmy and federated services in general, is that if you don’t agree with the moderation policies of one instance you are free to gather like minded people and put up one where you make the rules.
It’s as simple as that.
Well, I’m working on federation on another project. :) Thank you, though.
Not closer than I was a month ago sadly. I got bogged down in some C2S details.
That being said, my library has pretty much interchangeable C2S - S2S behaviour. Ie, the dev needs not worry about the distinction too much.
Returning to the ID problem. In ActivityPub the ID you expose when federating needs to be a fully qualified IRI, so multiple instances with containing the local numeric ID 1 should not a problem. Otherwise collisions would happen even if using UUIDs or some other non numeric sequence logic.
Why do you think you’re not able to use numeric ids?
I’m using these excuses (like your questions) to do a brain dump of some of the ideas I have in my head about federated link aggregators for a future blog post about it which hopefully be a bit more coherent.
Yeah, sorry. :)
My favourite read in the past 2-3 years was undoubtedly “The slow regard of silent things” a short story following one of the side characters of Patrick Rothfuss’ “The Kingkiller Chronicle”. However it’s not an easy to like read, in the author’s own words:
“You might not want to buy this book. […] even if you have read my other books, I think it’s only fair to warn you that this is a bit of a strange story. I don’t go for spoilers, but suffice to say that this one is … different.”
Another thing which I forgot to mention is computing/storing the scores for the posts.
In my implementation I have a real dumb way of doing it, where I just count the number of Likes/Dislikes on an item that represents the object and display that. The problem with this is that you need to load the collection that stores these on each object you want to display (eg: https://federated.id/objects/8592f693-d43f-4713-ba0c-86314520b787/likes ), which is very slow on a post with a lot of comments.
Probably a better way to do it would be to add a “Score” property to the objects (yeah, I forgot to mention that ActivityPub supports extensions :D) which would expose the precomputed score. I will probably get to adding that, but not anytime soon to be honest.
For a browseable ActivityPub service you can take a look at mine (probably you need a json beautifier extension in your browser):
Top level (a Service actor representing the server): https://federated.id
Actors collection (with filtering): https://federated.id/actors?type=Person&name=marius
Activities collection (with filtering): https://federated.id/activities?type=Create&type=Update
Objects collection (with filtering): https://federated.id/objects?type=Note
I’m not a lemmy dev, and I have no rust knowledge, but I can provide some of the issues I encountered while implementing activitypub libraries in Go.
The biggest issue in the begining was the Json-LD representation of ActivityPub, which allows a property to have different typed values: it can be a URL, a list of URLs, a single Object or a list of Objects. In Go, this is possible by using custom Json marshaling/unmarshaling and some hand-wavy interface usage. I’m not sure how well Rust fares in this respect, but it might be a solved problem already if there’s a jsonld crate somewhere.
The grammar/structure of the objects themselves is trivial and only requires one to create the types that represent the different activity streams vocabulary entities: Objects at the lowest level, Actors (which are just an alias for objects), Activities which are objects with a couple of extra properties. Some of the specific Object/Activity types have different structures, but again, nothing super complicated. I suspect this is a solved problem in the projects OP already mentioned in their other post.
Exposing the ActivityPub end-points. This is not super complicated, mainly each Actor (which is the AP representatoin of a user or, in the case of lemmy, a community) must have an end-point where other AP services can reach it. This Actor also needs outbox and inbox collection endpoints, which can be queried by external clients/services.
Implementing the Server to Server AcitivtyPub interactions (what is colloquially called “federating”). This is still work in progress for me, and probably this is where the major work will happen for Lemmy too. Basically an S2S interaction consists of a server (lemmy) disseminating a new post (let’s say) to the other servers. In AP grammar this means that a “Note”, “Article” object - in the case of self posts, or a “Page” object for links gets wrapped in a “Create” activity and gets dispatched to other servers.
First issue: you need to build a recipients list for the activity. The way this is being done is not very well documented, if at all. There is a Public namespace which should send to all servers that the current one has knowledge about. There are specific lists of recipients in the forms of an Actor’s followers (eg, all members of a community) or other actor collections, or just specific actors. (Think of a mail’s recipients list, and it’s basically the same, except for the public namespace).
Second issue: authorizing the requests to the other servers. This is generally being done by using the HTTP-Signatures mechanism. Every actors needs public/private keys, that are used for signing the requests to other servers. This is probably also a solved case for rust.
Then there’s user discovery. Which you need when your server receives an activity from somewhere else. You need to load the Actor that created the activity and load their public key to validate the request’s http-signature.
In mastodon land, user discovery is being done by using web-finger. On my project I use plain ActiviytPub with a custom end-point for actors.
Now, all of this was a very light explanation of how/what’s needed to dispatch a single post from lemmy. ActivityPub has a number of other activity types that need to be implemented: Like/Dislike for voting, Update/Delete for content editing/deleting, Follow/Accept/Reject for community/user following, Announce for admin/user announcements, etc.
Each of these most probably will require custom logic - which unfortunatelly is documented only at the most superficial level in the ActivityPub spec, and much is left to the implementors.
So, in conclusion, this is no trivial amount of work, probably the devs have documented some of these steps in their issue tracker and maybe that’s a good place to start looking for low hanging fruit.
Good luck. :)
Thanx for the shout out.
I hope so too. :)
I replied here to someone asking about differences regarding Prismo and I think it can be said compared to Lemmy also.
Nope, I am not affiliated with them in any way.
Reddit alternatives might be a good place to post too, but I see it already has a post about Lemmy.
On my part that will definitely happen. :)
Well, there are some differences. Biggest of all, is that they are being developed on different tech stacks. I am not a rust dev, and probably won’t be much help. I can provide answers to questions that I might have solved already (since I have a bit more experience on the ActivityPub front), or we can brainstorm about how to better interoperate, but I think that for the forseable future they’re going to be two different efforts. Sorry.
Test